I'm not a developer, but I don't mind being called a fanboy for something like this.
And no, there's no reason why another OS couldn't use a TPM in the same way. Qubes seems to be the only one so far with this interesting feature.
Anti Evil Maid was designed initially for physical attacks, as the name implies. It does eliminate the 'Evil Maid' scenario if its assumed the attacker is unskilled and/or only has time to plug a USB or similar device into the computer. So it greatly reduces the opportunity for successful physical attacks.
For remote attacks against motherboard firmware, AEM ought to work 100% of the time. This is especially true if you have disabled booting from internal drives, in which case your HD firmware could become compromised and still not be able to obtain any unencrypted keys or data.
Qubes R3 will have an unprivileged storage domain which should protect you even if the HD firmware is *already* infected or indeterminate at install time.
The best way to deal with the situation is to run browsers under a hardened type-1 hypervisor that has a tiny attack surface itself. Create an 'untrusted' domain and tool around the Internet to your heart's content, or use disposable VMs that appear for risky temporary tasks and then self-delete.
If we want this rich content in our lives we have to accept the complexity and the risk to some degree. Using an OS built on security by isolation allows us all that complexity, but behind very strong, simple security structures that are built on the best hardware virtualization features. This is probably the only good way to keep private data and core systems from being exploited.
I even have reservations about air-gapping as a 'good' security solution: As the practice stands with PCs now, its too free-form and there are too many complex code layers to think about and work around while sneaker-netting info and code between systems. A USB device that got infected could pretend to be any of hundreds of devices that use dodgy, vulnerable drivers; and that doesn't even touch on the risk from complex file formats or desktop features.
That is not such a big difference, considering most installations are still using OpenSSL (more eyes...).
LibreSSL is still valued for their efforts, but they and most of the IT community waited until a major crisis occurred before taking action. Now that OpenSSL has been in the spotlight and finally received decent funding to do their own reviews and cleanup, I'm not sure where that leaves LibreSSL.
I'm guessing Fedora will have it in about 5-10 days, during which time about three 100MB Libre Office updates will already have been posted to their mirrors.
What's infuriating is that USB drives used to come with hardware write switches and now you can't find them anywhere. And motherboards used to require you to move a jumper to flash the BIOS but, those are gone too. I don't know if it was cost cutting or a case of user stupidity or both but, the hardware write switch has faded into history. I'm fine with the being in a default-write setup as long as they had the option to cut it off.
A third possibility is that the NSA and their friends abroad might have pressured the manufacturers to remove these security features. The pressure might have subtle, like pointing out "good" places for cost savings.
As someone else mentioned, Kanguru has write protect (and I think a few others -- I have some drives by Imation and RiData that have the switch). But that doesn't necessarily protect you from something like badUSB, which can infect drive firmware.
Kanguru states their drive firmwares are protected with digital signatures. However, that means the firmwares are writeable under certain conditions, and we now know that certain organizations make it their job to steal the private keys of security vendors (you can bet the practice is not limited to SIM cards). In that case, you may be better off with a 'plain' thumb drive that has a non-changeable firmware especially if it has a write-protect switch.
What really, really sucks is that virtually no manufacturers are stepping up to the plate with better hardware designs that can mitigate the problem... and even the OPAL2 spec appears to state that firmware protection is optional. Merely putting write-protect jumpers on the firmware storage chips would prevent most attacks (the remote ones).
An exception to the lack of manufacturer concern may be the new Purism brand that just launched their Librem 15 OSS-friendly laptop. They are interested in putting at least a jumper on the motherboard that can block BIOS changes. They also promise to release an edition of the Librem that allows the user to cut power to wireless, mic and camera.
Another mitigation is Qubes OS, which has an architecture that greatly ups the bar for security and it can detect tampering in the BIOS, kernel, hypervisor, etc.
Qubes OS will detect this type of attack, and in most cases prevent it. It can also protect you against badUSB if you create a USBVM to handle the USB controllers.
Detection comes via the Anti-Evil Maid package, which uses a TPM to measure the system firmware, bootloader, kernel and hypervisor. It optionally can create a USB thumbdrive for booting Qubes in AEM mode. (AEM should *always* detect a compromised base system, but using a thumbdrive can help prevent an attack from succeeding in an 'Evil Maid' scenario.)
Qubes uses Xen, a type 1 bare-metal hypervisor with a miniscule attack surface, and uses that as a chokepoint to regulate ALL system activity (including network and graphics) in a way other OSes do not. Graphics is one of the weaknesses in VM host security that enables 'VM Breakout' escalation attacks. In using VMs for all sensitive functions, remote attacks are highly unlikely to escalate and take over the core system or firmware.
I won't say there is nothing irrational about the marketing of organic food. But organic farming does largely achieve its primary goals: Keeping the soil healthy and lowering pesticide exposure.
As for vegans, they are simply against animal exploitation and cruelty. Its not a scientific issue.
The way that conservatives attempt to pick at the 'irrationality' of others is instructional here. Its really a defense of large, exploitive industries with monopolistic tendencies. OTOH, the manner in which conservatives escape abusive industries is to form communities like the Amish or Christian Scientists, which IMO are worse than the problem.
I think the only "point" in this sub-thread is that the 'temporarily embarrassed billionaires' are shilling for oligarchs by shifting the focus of a discussion about national politics to the globe.
It's already implemented. The powers that be have chosen "No one is cyber-secure" for you.
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.
Oh and by the way, want to know if their hacking attempts were successful or not? That's easy to determine now.
Is any Blackphone service still legal to use?
You now have your answer.
Enjoy the illusion of privacy.
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.
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.
User error could happen with any system. You're really stretching here.
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.
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.
Where did I ever say any of these computers had hard discs?
LOL! OK you 'win' that one. Let's do without mass storage...
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.
This whole notion you have that "the operating system is insecure so let's put another layer on top of it" is just silly. If you make Xen your operating system, then Xen is your operating system.
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.
True security comes from simplicity, not complexity.
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.
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.
I'm saying rooting a machine to the point that it can customize an arbitrary USB key plugged in by the legitimate operator of the machine is impractical.
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.
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.
- Firejail. Google it. Won't protect you against local kernel privilege escalation attacks, though.
Yes, contingency planning is good. Yes, single points of failure are bad. But you can get very, very good communication security if you really try.
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.
Slashdot Mirror
I'm not a developer, but I don't mind being called a fanboy for something like this.
And no, there's no reason why another OS couldn't use a TPM in the same way. Qubes seems to be the only one so far with this interesting feature.
Anti Evil Maid was designed initially for physical attacks, as the name implies. It does eliminate the 'Evil Maid' scenario if its assumed the attacker is unskilled and/or only has time to plug a USB or similar device into the computer. So it greatly reduces the opportunity for successful physical attacks.
For remote attacks against motherboard firmware, AEM ought to work 100% of the time. This is especially true if you have disabled booting from internal drives, in which case your HD firmware could become compromised and still not be able to obtain any unencrypted keys or data.
Qubes R3 will have an unprivileged storage domain which should protect you even if the HD firmware is *already* infected or indeterminate at install time.
The best way to deal with the situation is to run browsers under a hardened type-1 hypervisor that has a tiny attack surface itself. Create an 'untrusted' domain and tool around the Internet to your heart's content, or use disposable VMs that appear for risky temporary tasks and then self-delete.
If we want this rich content in our lives we have to accept the complexity and the risk to some degree. Using an OS built on security by isolation allows us all that complexity, but behind very strong, simple security structures that are built on the best hardware virtualization features. This is probably the only good way to keep private data and core systems from being exploited.
I even have reservations about air-gapping as a 'good' security solution: As the practice stands with PCs now, its too free-form and there are too many complex code layers to think about and work around while sneaker-netting info and code between systems. A USB device that got infected could pretend to be any of hundreds of devices that use dodgy, vulnerable drivers; and that doesn't even touch on the risk from complex file formats or desktop features.
That is not such a big difference, considering most installations are still using OpenSSL (more eyes...).
LibreSSL is still valued for their efforts, but they and most of the IT community waited until a major crisis occurred before taking action. Now that OpenSSL has been in the spotlight and finally received decent funding to do their own reviews and cleanup, I'm not sure where that leaves LibreSSL.
I'm guessing Fedora will have it in about 5-10 days, during which time about three 100MB Libre Office updates will already have been posted to their mirrors.
PS- Hi Timothy! :wave: Slashdot won't let me change my sig...... :D
What's infuriating is that USB drives used to come with hardware write switches and now you can't find them anywhere. And motherboards used to require you to move a jumper to flash the BIOS but, those are gone too. I don't know if it was cost cutting or a case of user stupidity or both but, the hardware write switch has faded into history. I'm fine with the being in a default-write setup as long as they had the option to cut it off.
A third possibility is that the NSA and their friends abroad might have pressured the manufacturers to remove these security features. The pressure might have subtle, like pointing out "good" places for cost savings.
As someone else mentioned, Kanguru has write protect (and I think a few others -- I have some drives by Imation and RiData that have the switch). But that doesn't necessarily protect you from something like badUSB, which can infect drive firmware.
Kanguru states their drive firmwares are protected with digital signatures. However, that means the firmwares are writeable under certain conditions, and we now know that certain organizations make it their job to steal the private keys of security vendors (you can bet the practice is not limited to SIM cards). In that case, you may be better off with a 'plain' thumb drive that has a non-changeable firmware especially if it has a write-protect switch.
What really, really sucks is that virtually no manufacturers are stepping up to the plate with better hardware designs that can mitigate the problem... and even the OPAL2 spec appears to state that firmware protection is optional. Merely putting write-protect jumpers on the firmware storage chips would prevent most attacks (the remote ones).
An exception to the lack of manufacturer concern may be the new Purism brand that just launched their Librem 15 OSS-friendly laptop. They are interested in putting at least a jumper on the motherboard that can block BIOS changes. They also promise to release an edition of the Librem that allows the user to cut power to wireless, mic and camera.
Another mitigation is Qubes OS, which has an architecture that greatly ups the bar for security and it can detect tampering in the BIOS, kernel, hypervisor, etc.
Qubes OS will detect this type of attack, and in most cases prevent it. It can also protect you against badUSB if you create a USBVM to handle the USB controllers.
Detection comes via the Anti-Evil Maid package, which uses a TPM to measure the system firmware, bootloader, kernel and hypervisor. It optionally can create a USB thumbdrive for booting Qubes in AEM mode. (AEM should *always* detect a compromised base system, but using a thumbdrive can help prevent an attack from succeeding in an 'Evil Maid' scenario.)
Qubes uses Xen, a type 1 bare-metal hypervisor with a miniscule attack surface, and uses that as a chokepoint to regulate ALL system activity (including network and graphics) in a way other OSes do not. Graphics is one of the weaknesses in VM host security that enables 'VM Breakout' escalation attacks. In using VMs for all sensitive functions, remote attacks are highly unlikely to escalate and take over the core system or firmware.
This is a very interesting choice: Great display and extremely high Linux compatibility.
I won't say there is nothing irrational about the marketing of organic food. But organic farming does largely achieve its primary goals: Keeping the soil healthy and lowering pesticide exposure.
As for vegans, they are simply against animal exploitation and cruelty. Its not a scientific issue.
The way that conservatives attempt to pick at the 'irrationality' of others is instructional here. Its really a defense of large, exploitive industries with monopolistic tendencies. OTOH, the manner in which conservatives escape abusive industries is to form communities like the Amish or Christian Scientists, which IMO are worse than the problem.
I think the only "point" in this sub-thread is that the 'temporarily embarrassed billionaires' are shilling for oligarchs by shifting the focus of a discussion about national politics to the globe.
They come in full-size and mini versions, wired-with-hub and also wireless...
http://www.matias.ca/
If the intermediaries matter, you're doing it wrong.
It's already implemented.
The powers that be have chosen "No one is cyber-secure" for you.
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.
Oh and by the way, want to know if their hacking attempts were successful or not? That's easy to determine now.
Is any Blackphone service still legal to use?
You now have your answer.
Enjoy the illusion of privacy.
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.
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.
User error could happen with any system. You're really stretching here.
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.
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.
Where did I ever say any of these computers had hard discs?
LOL! OK you 'win' that one. Let's do without mass storage...
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.
This whole notion you have that "the operating system is insecure so let's put another layer on top of it" is just silly. If you make Xen your operating system, then Xen is your operating system.
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.
True security comes from simplicity, not complexity.
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.
I'm saying rooting a machine to the point that it can customize an arbitrary USB key plugged in by the legitimate operator of the machine is impractical.
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 :) )
- Firejail. Google it. Won't protect you against local kernel privilege escalation attacks, though.
Yes, contingency planning is good. Yes, single points of failure are bad. But you can get very, very good communication security if you really try.
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.