If the intermediaries matter, you're doing it wrong.

Granted, nothing is perfect. But I'd like to see any demonstration of hacking a system like this.

Or, rather, I'd like to see them try.

Real network security is defined by the quality of its endpoints. And to have secure endpoints we need a personal computing culture that values openness as the first step to better security.

Now there is an example of actual paranoia: The black and white thinking, the raising of a perceived enemy to super-human abilities.

The world is in a CRISIS over privacy right now, and there is still much to this issue that is up in the air.

Do I think the US government is capable of *trying* to censor crypto? Yes, eventually it may happen. But only if/when housing and food become much more expensive... Then you would see the (small) difference between the US government and third world dictatorships disappear and we wouldn't be having these kinds of conversations.

Indeed, all code has bugs. Its a question of who/what is using the least amount of code necessary to provide a security mechanism. That's what reducing the attack surface is really about.

From a security standpoint, Qubes would by definition have very few-to-no additional bugs above what exist in Xen. OTOH, as I have implied, a Linux or Windows kernel + supporting libraries and also the firmware for USB controllers and NICs are immense compared to Xen plus a couple Qubes drivers (there is more to Qubes code, but only a small bit is critical to security).

I'm just pointing out that air-gapping does rely on the good behavior of an awful lot of code at its security perimeters. And it is TWO or more perimeters, not one, because you are putting some faith in the networked machine(s) being well-behaved as well.

And why should a user be burdened with a detail like controlling automount behavior? Its exactly the kind of thing you see in the papers when people are hacked. And it raises the question of how much of a tireless control freak you have to be to make a security schema work.

Its much safer to have a core domain that simply doesn't mount any extra volumes and is cut off from the network. One can quickly dispatch a disposable vm to look at the contents of a drive or copy something.

LOL! OK you 'win' that one. Let's do without mass storage...

As I pointed out, Xen is tiny. Its not being layered on top of anything.

Hypervisors vary in their security focus; Most are designed to re-purpose a CPU security mechanism as a way to conveniently maximize hardware usage or run alternative OSes. They don't care much about security, especially on the desktop where they focus on convenience alone. They expose graphics, audio, clipboard, etc. in ways that practically define the category of vm-breakout exploits.

Xen cares very much about security on the server, and Qubes adds what is necessary to extend that to the desktop by properly virtualizing the graphics subsystem along with everything else, for example.

I agree -- However, functionality comes from complexity. So the solution becomes using simple security mechanisms to manage the de-privileged complexity.

It has been fun arguing over two different isolation mechanisms. Air-gapping is not often discussed in detail, and it would be nice to see sites like /. carry more posts about all of the above.

The mass media (aka 'infotainment complex') is a prime example that if you tell the facts all day about fires, robberies, weather, and (selectively) arrests... then you gain a certain credibility to use in starting a war, or to keep suggesting that everyone on the street is just a temporarily embarrassed billionaire (if only the government would stop this regulation stuff).

Its possible Google's new ranking idea could be a benefit to humanity IF they make the logic and the rankings transparent. That would at least allow the raters to be rated by watchdogs.

(Oops, that should read "Anti-Evil-MaiD feature.")

I'm glad someone made a point about security by obscurity.

The OPAL 2 spec. does mention guarding firmware updates in section 5, but it does not appear to be compulsory (and no one I'm aware of from the HD industry has said anything yet...).

A: Use an OS that cordons off any possibility of accessing the HD or other firmwares to begin with. The Xen hypervisor prides itself on being more secure than most, and its only about 1MB in size. Using that small and hardened attack surface as the gatekeeper to all hardware functions (including NIC and graphics), and as the means of silo-ing one's computing life into work, personal, misc online, etc., its perhaps the best defence out there for PCs. The Qubes GUI even lets you sequester USB controllers inside specific VMs and as such its a line of defence against badUSB. To top it off, it gives you facilities like splitGPG, isolated TorVM, and a means of sanitizing pdfs.

Even if you only use it to separate "online" from "offline" stuff (or even if you only use it as an untrusted "online" system), Qubes will protect the core system such as BIOS and other firmware.

FWIW & BTW, I've read parts of the OPAL 2 spec. for hard drives that states a drive manufacturer should make functions like firmware update conditional on successful authentication (no firmware update without the correct password). But it isn't clear to me whether OEMs are complying with what appears to be a recommendation.

OTOH, you could get a high-security flash drive (the kind with signed updates or read-only firmware) then put your Qubes boot partition on that and enable the Anti-Evil-Mail feature. I think Kanguru and IronKey are two such drive vendors.

Except that privilege escalation attacks against these multi-decade-old systems appear year after year. A well-funded state attacker (OP is about activists, after all) would certainly have some at their disposal.

Which gets back to the premise that monolithic kernels enforcing user privs is an outmoded form of security. Re-purpose the kernels as feature sets under an isolating hypervisor and security begins to look realistic.

Re: CD-R, lets assume I use an optical disk to move a quantity of email messages from a networked/untrusted machine to an airgapped one (both conventional architecture). If I export as .eml files, I have to archive them before burning them. So, over and above the risk from nasty email attachments, there is the risk the untrusted machine could use malformed email or archive format to perform an exploit. If you think that's far-fetched, consider how much more complex email and archive formats are compared to the .lnk files that were recently discovered as an NSA exploit.

Even so, the untrusted networked system could take a chance that you have automounting enabled or that you will inadvertently do something to mount a volume... it could write a malformed filesystem to the disc anyway.

Once an air-gapped system is compromised, it can alter the hard drive firmware to store passwords and keys in a format/cipher readable by the attacker who can later break-in to the premises and steal/confiscate the computer. In a Qubes non-networked vm, there is no out-of-band way to communicate or store info, and a compromised vm wouldn't have access to the disc encryption password in any case.

What you described #s 1-5 sounds much more complicated than using email in Qubes. And presumably this covers only email for one type of role (work, personal, etc); Covering all the roles means using many additional computers and burning many discs, and each role needs its own disc encryption passphrase.

If the email domain is untrusted, then create an untrusted Qubes vm for it. I could even create one vm for each role, plus one archival non-networked vm to store info, and even if the archival vm were compromised there's nothing it can really do except try to erase the data in that one vm. Securely copying between the vms is point-and-click (easier, in fact, than between user sandboxes on a regular system) or scriptable... one only needs to consider how risky the source and formats are to the destination vm. If there is a need to sanitize the info, its easy to do so in a Disposable vm (right now Qubes can sanitize pdf files, and other formats are expected). The only unintuitive caveat in such a virtualized setup is that sensitive asymmetric encryption (operations that use the private key) has to occur while untrusted VMs are not running in order to avoid side-channel attacks.

If the USB host controller firmware or any of the USB drivers available to the system are exploited, then malware delivered by the USB device may get use of the DMA channel between the host controller and RAM (if not simply gain root access). And calling customization of a device impractical is, I think, leaning a bit towards denial -- many hobbyists can do this now. Familiarity with common controller types used in consumer devices is also rising.

Its probably safer to bet security on a chokepoint like Xen hypervisor (which uses microkernel architecture and is only 1MB) than to use portable USB devices between air gapped machines. With the latter, any / all of the USB drivers plus a good chunk of the OS represent the attack surface.

The air gap user is relying on a riot of very disparate components, mostly authored by people who treat security as a mere buzzword.

If Internet security improves, we'll likely see more USB-based attacks in the wild. Sneaker-net may have high latency but its still a network.

You've got the wrong impression of BadUSB as impersonating a HID certainly isn't required. USB is fundamentally insecure in a number of ways...

https://www.blackhat.com/prese...

http://media.blackhat.com/bh-d...

https://srlabs.de/blog/wp-cont...

When the USB drivers themselves can be attacked with malformed protocol data there is a fairly direct channel to gaining access to the whole system. Also a USB drive controller can make itself look like an internal drive, meaning that DMA (yes, USB supports DMA) restrictions get lifted and then you have a hole in security similar to Firewire.

As for filesystem attacks being 'rare', that's only because other attacks (esp. remote) have offered so much opportunity to attackers. If an attacker wants an offline mode of exploitation then filesystems -- being complex data formats themselves -- then filesystems are a wide-open field of opportunity.

Due to risks like BadUSB, or even attacks using the filesystem itself, those methods carry risk of exploiting the air-gapped system.

IMO, its actually better to use an isolating OS like Qubes because it uses a simplified and hardened protocol for data transfer between domains. Even copy-and-paste between domains has been hardened. It can isolate USB controllers and external disks at the hardware level using the IOMMU/VT-d feature in newer chipsets.

"The traditional security model of monolithic OS kernels" ...have been abandoned because they don't work against external threats. Of course, that doesn't prevent you from using traditional security within a Qubes VM.

(Sorry. Finishing sentence from previous post :) )

Qubes OS should protect you against privilege escalation *and* VM breakout attacks where sandboxes like 'Firejail' do not. Its a hardened hypervisor-based desktop OS that isolates elements like graphics and network IO from each other using a system's IOMMU if necessary. Its single-user, and all security is implemented using the hypervisor.

Qubes is put out by white-hat hacker group Invisible Things Lab who switched their focus when they saw the need to do something about endpoint security. Their philosophy is to use the strongest means possible for isolation short of airgapping as a way to manage the complexity (large attack surface) of the personal computing environment; The security models of monolithic OS kernels

A bonus of isolating all the risky activities away from the graphics system is exposition: The windowing system becomes a reliable means to represent security context using window-frame colors and domain labels assigned by the user to the various VM domains.

I'll grant that Enigmail rectifies the display problem ...but Enigmail is neither the OS nor the application. By default, the uninitiated will see gross text and that is because (as I said) crypto isn't given first-class treatment in UIs.

TB sans Enigmail could at a bare minimum parse the guard lines and fold the contents into something like the UI for attachments. Or it could just incorporate Enigmail functions in the main program.