Unlikely: there were a ton of server, desktop, and embedded virtualization projects and products before QubesOS. I listed them on their mailing list asking why they were reinventing the wheel instead of building on established work or improving hardware after they showed it was so flawed. Joanna's counter-arguments were disturbing and easily countered. Then she just started censoring any of my critiques on her blog while allowing positive comments lol. Promotes confidence in its security and her comment section's accuracy...
Anyway, if OpenBSD copies anyone, I'd say copy the Nizza Security or Genode Architectures. They leverage the kind of good components (eg Nitpicker/NOVA) and tactics (eg resource management) I mentioned to QubesOS. I see Qubes since adopted a similar tactic in their graphics system. Has a few novelties but mostly a rehash of virtualization and CMW stuff good against common malware. Need stronger TCB and methods to stop nation-states. Other work at least goes in that direction although not there yet either.
They did one thing really well. They actually provide a running system. You linked to Nizza and EROS papers, not software. Genode provides a "framework" - and basically runs complete systems in separate windows.
QubesOS provides a familiar environment where applications can be labeled with different security contexts and run completely isolated from each other. Basically they win on execution right now. I'm sure there are loads of interesting approaches and papers describing how to make things better. But QubesOS is a product and it works. It also provides a user documentation, while genode docs give you c function signatures.
Oh yeah, they did build a running system. It was in similar status to the others (eg Dresden's TUDOS) when I made my recommendations. All needed work with QubesOS getting plenty from its dedicated team. Put enough work into something and it will certainly run: see Windows 3.1 on MS-DOS. ;) QubesOS is way better naturally but shows the point that "it runs" doesn't invalidate any design or security claim made about it. Nor is it an excuse for using a bad approach or failing to adapt. Reminds me of programmers with defective code that argue, "But mine ran faster!"
That said, it's usable enough that even I recommend it as an option when strong attackers aren't the opponents. If the attackers are, then it's unlikely to save you and work should be put into the inherently stronger options to get them in better shape. Plus, there's some commercial separation kernels that already run on desktops/laptops etc. one can use. They all use security-focused kernels, user-mode drivers, user-mode networking stacks w/ hardening, trusted boot, I/O MMU, and so on. Not cheap, though, plus a risk of subversion or someone cutting corners. Decisions, decisions. ;)
Truth be told, the whole market (proprietary + FOSS) sucks one way or another. Enemies are probably going to get in if it's a desktop due need to be compatible with much risky garbage. Only the console approaches can be made strong enough with FOSS components right now. Tough trade-offs in ease-of-use, too.
My current recommendation for defending against strong attackers is my old approach: several cheap, hardened machines for physical separation with KVM switch; a guard for sharing between them; sharing done over non-DMA, simple interfaces with simple, easy-to-parse protocols. Additionally, no wireless functionality (even disabled) in them at all. Worked before and still works for less than $1,000 but it ain't pretty or easy to setup.
"Genode provides a "framework" - and basically runs complete systems in separate windows."
Actually, it's a [barely-]usable system differentiated by a resource-management scheme, pluggable microkernels, minimal-TCB native apps, and/or running "complete systems in separate windows." Splitting between microkernel apps and VM's is a proven method that resisted NSA hackers in prior evaluations (eg XTS-400, INTEGRITY-178B). Part that really needs review for risks is their resource-management scheme. However, if proven, it will be advantageous in benefits it offers and especially if microkernel/microhypervisor is enhanced with INTEGRITY RTOS-style resource controls. Malicious apps mostly wouldn't be able to do shit unless there were hardware flaws or problems in the few, trusted components.
Meanwhile, QubesOS runs. So do my Linux LiveCD's and KVM boxes. Malware doesn't hit any of them because the best aren't trying: most targets use Windows or predictable Linux builds. We'll keep using such obfuscation until the [FOSS] strong stuff is ready.
> My current recommendation for defending against strong attackers is my old approach: several cheap, hardened machines for physical separation with KVM switch; a guard for sharing between them; sharing done over non-DMA, simple interfaces with simple, easy-to-parse protocols.
Could you share more about the physical transport for sharing, the data guard (is that a separate box with a Live CD) and wire protocols?
How do you protect against physical threats to unattended devices/data, e.g. do you have any form of trusted boot to verify the integrity of the BIOS, bootloader and OS?
There is no protection for unattended devices lol. That's a huge cat and mouse game. It's why I used to use little embedded boxes like ARTIGO's which were easy to stash along with tamper-evidence tricks. If there was tampering, can't be trusted any more. The few times turned out to be a roommate bumbling around for some ridiculous reason.
There are many physical transports to use. My original hack was IDE in a non-DMA mode to get past serial's speed limits. Then I/O offloading onto dedicated, cheap computers to pre-process the data and force it into correct spot. Next step was synthesis of the same onto cheap, I/O-focused FPGA's or microcontrollers before I had to put a pause on those developments.
The guard [1] is the strongest part. It used simple hardware(s), a security-focused microkernel, carefully written drivers, optional middleware for internal flow control, and separate partitions for each logical function. Anything incoming is fully scrutinized before moving on. Certain protections, such as encryption, might be applied automatically. The modular, layered, often FSM-using implementation of each thing allows the highest amounts of analysis and verification w/ many errors provably absent. You can also gradually add advanced security technology as it comes online such as SecureCore, Cambrige's CHERI processor, DIFT, Softbound + CETS, etc.
So, the concept is physical separation into different domains. The computers use what they need to use. The Internet-facing ones typically did use LiveCD's and BIOS's I could protect to a degree (eg oldest boxes had jumpers). If it wasn't LiveCD, it was regularly restored from clean backups. Virtualization, hardening, and mandatory controls used as appropriate but I assume it will be toast. Simpler formats like text, HTML 3.2, BMP, and so on for easy analysis by guard. If complex stuff is allowed, it goes over a data diode so any malware isn't leaking things back.
For a similar approach at network/host level, see Boeing's OASIS Architecture [3] that builds on their high-assurance Embedded Firewall (PCI card), SNS Server (highest rating/field-use ever), and a bunch of custom components/strategies. Post-police-state, I'm basically just swapping out Linux distro's as I can't afford to build my old setups any more. My current R&D is on tools such as crash-safe.org, CHERI (w/ CHERIBSD), and the cryptographic methods that all protect system confidentiality and integrity from hardware up. Been working on verified ASIC development flow to implement them with that being done up to RTL level. Current explorations are High-level Synthesis, Analog Synthesis, and my medium-high-assurance RAD methods for software. Post most of my results on Schneier.com, etc instead of my own blog for impact with some companies copying it without credit that we've seen. I can email you those if I haven't.
Couldn't find it last I Google'd for whatever reason. Could've been lost, moved, or another thing she censored. Started with a conversation on one forum where I mentioned prior work and separation kernels. A reader brought it up on QubesOS mailing list with Joanna dismissing it and cutting our comments down. So, if you're wondering about my tone, that's why. She exploded on me with ranting nonsense mixed with some useful points about her position. Went back and forth a few rounds.
Anyway, my cross-domain system saved a copy of my end of the conversation. My style is to fairly quote other person before each reply so context is obvious to readers. Anything else was ranting filler that was unimportant. You'll be able to clearly see what she was saying. Here's a Pastebin of the two logs.
For what it's worth, I've found the Qubes team to be combative and defensive at times. I especially recall not managing to get straight answers about their VPN and Tor networking modules. But then, both were contributions from users, so their apparently dismissive attitude wasn't totally outrageous.
Good to know it wasn't just my own anti-charismatic personality. ;) That she didn't see the value of user-mode drivers for robustness and thought Darwin was representative of microkernel design were both disturbing in terms of "Should I trust this?" It's like they were smart on the things they published but didn't have a clue about security engineering outside of that.
So, I have no intention of ever depending on it for strong security: just maybe regular malware or containing effects of spyware, bloat, etc.
The best path to strong security has always been hardware isolation, right? So now that we have mass-market microcomputers, why bother with VMs? What do you think of Tinfoil Chat[0]? The notebook form factor could contain several microcomputers, with optical isolation, or even outright air gapping. But closed-source hardware and firmware is still problematic :(
Closed source hardware is indeed a problem: If the HW of TxM is pre-compromised, the device/malware running on it might spit out what it thinks is the key via serial or alternative covert channel.
If you start developing on top of TFC, please create a Github fork at some point and submit pull requests to any typos / issues you might find.
Not really. I started thinking that but not really sure. There's a number of models. The thing the preventative ones all have in common is they impose control on the flow of information in such as way as to prevent attacks. Separation, like address spaces, is a recurring concept and technique but not the only one. So, I use the term "information flow control" albeit it might be used differently in academia. The other model, covered by diversity and obfuscation, is to create a disconnect between what attacker envisions and what they can accomplish to create probabilistic security. The first is great against "known knowns" and "known unknowns:" specific attacks or non-specific worries in known risk areas. The second is great against straight unknowns, esp tricks nation states devise. Combining the two is most powerful and hence my recommendation. Many models of each, which further muddles things for attackers.
Far as Tinfoil Chat, I've recommended it heartily as a project to use and improve. Markus Ottela took what he learned from prior work and our comments at Schneier's blog (esp on data diodes & physical separation) to create a unique, solid design. He's been posting on the blog for feedback for months, we've suggested many risk mitigations (eg polyciphers, continuous transmission), and he's integrated about every one into his system. Most just ignore such things or make excuses: Markus is 1 in a 1,000 in (a) applying what's proven and (b) not letting problems become legacy "features."
So, yeah, I recommend it. Once my personal situation stabilizes, I plan to reimplement it with a tiny TCB on appropriate devices. I'm probably going to do a portable implementation of Send for microcontroller-style systems. Receive will be a Linux box hardened with virtualization or obfuscation security methods. Genode if it's up to it by then. The transport will be a more hardened, cheap box with just that functionality. I'm going to use CHERIBSD, if possible, just to experiment with it. Might replace the raw, serial links with MCU's or FPGA's for higher-speed, one-way I/O. Optical is highly likely (good guess). Eventually, I'm going to put it in an appliance with several, cheap boards so it's all integrated.
On my extensive backlog for now. But, yes, it's one of the best and practically has no TCB. Great design. Can be reused for email, audio, video, and maybe filesharing. Will be my interim framework until my next high-assurance system is ready.
It's gotten backlogged for me too. I started obsessing about potential EM coupling across optoisolators. But to test, I need a Faraday cage and gear. ...
Anyway, I'll check out the discussion on Schneier's blog.
It's kind of spread out all over the place lol. Would be difficult to even integrate. For Tinfoil, it's best to just grab the code of the Poly variety and start using/improving it. Far as the 100+ other topics, I can give you a list of links to my designs and essays there if you want to dig through for something worth building on. All I ask is credit as Nick P for whatever part my work contributes.
Comments
Unlikely: there were a ton of server, desktop, and embedded virtualization projects and products before QubesOS. I listed them on their mailing list asking why they were reinventing the wheel instead of building on established work or improving hardware after they showed it was so flawed. Joanna's counter-arguments were disturbing and easily countered. Then she just started censoring any of my critiques on her blog while allowing positive comments lol. Promotes confidence in its security and her comment section's accuracy...
Anyway, if OpenBSD copies anyone, I'd say copy the Nizza Security or Genode Architectures. They leverage the kind of good components (eg Nitpicker/NOVA) and tactics (eg resource management) I mentioned to QubesOS. I see Qubes since adopted a similar tactic in their graphics system. Has a few novelties but mostly a rehash of virtualization and CMW stuff good against common malware. Need stronger TCB and methods to stop nation-states. Other work at least goes in that direction although not there yet either.
Nizza Security Architecture https://os.inf.tu-dresden.de/papers_ps/nizza.pdf
Genode http://genode.org/
EROS (example of one of best approaches) http://www.eros-os.org/papers/IEEE-Software-Jan-2002.pdf
They did one thing really well. They actually provide a running system. You linked to Nizza and EROS papers, not software. Genode provides a "framework" - and basically runs complete systems in separate windows.
QubesOS provides a familiar environment where applications can be labeled with different security contexts and run completely isolated from each other. Basically they win on execution right now. I'm sure there are loads of interesting approaches and papers describing how to make things better. But QubesOS is a product and it works. It also provides a user documentation, while genode docs give you c function signatures.
Oh yeah, they did build a running system. It was in similar status to the others (eg Dresden's TUDOS) when I made my recommendations. All needed work with QubesOS getting plenty from its dedicated team. Put enough work into something and it will certainly run: see Windows 3.1 on MS-DOS. ;) QubesOS is way better naturally but shows the point that "it runs" doesn't invalidate any design or security claim made about it. Nor is it an excuse for using a bad approach or failing to adapt. Reminds me of programmers with defective code that argue, "But mine ran faster!"
That said, it's usable enough that even I recommend it as an option when strong attackers aren't the opponents. If the attackers are, then it's unlikely to save you and work should be put into the inherently stronger options to get them in better shape. Plus, there's some commercial separation kernels that already run on desktops/laptops etc. one can use. They all use security-focused kernels, user-mode drivers, user-mode networking stacks w/ hardening, trusted boot, I/O MMU, and so on. Not cheap, though, plus a risk of subversion or someone cutting corners. Decisions, decisions. ;)
Truth be told, the whole market (proprietary + FOSS) sucks one way or another. Enemies are probably going to get in if it's a desktop due need to be compatible with much risky garbage. Only the console approaches can be made strong enough with FOSS components right now. Tough trade-offs in ease-of-use, too.
My current recommendation for defending against strong attackers is my old approach: several cheap, hardened machines for physical separation with KVM switch; a guard for sharing between them; sharing done over non-DMA, simple interfaces with simple, easy-to-parse protocols. Additionally, no wireless functionality (even disabled) in them at all. Worked before and still works for less than $1,000 but it ain't pretty or easy to setup.
"Genode provides a "framework" - and basically runs complete systems in separate windows."
Actually, it's a [barely-]usable system differentiated by a resource-management scheme, pluggable microkernels, minimal-TCB native apps, and/or running "complete systems in separate windows." Splitting between microkernel apps and VM's is a proven method that resisted NSA hackers in prior evaluations (eg XTS-400, INTEGRITY-178B). Part that really needs review for risks is their resource-management scheme. However, if proven, it will be advantageous in benefits it offers and especially if microkernel/microhypervisor is enhanced with INTEGRITY RTOS-style resource controls. Malicious apps mostly wouldn't be able to do shit unless there were hardware flaws or problems in the few, trusted components.
Meanwhile, QubesOS runs. So do my Linux LiveCD's and KVM boxes. Malware doesn't hit any of them because the best aren't trying: most targets use Windows or predictable Linux builds. We'll keep using such obfuscation until the [FOSS] strong stuff is ready.
> My current recommendation for defending against strong attackers is my old approach: several cheap, hardened machines for physical separation with KVM switch; a guard for sharing between them; sharing done over non-DMA, simple interfaces with simple, easy-to-parse protocols.
Could you share more about the physical transport for sharing, the data guard (is that a separate box with a Live CD) and wire protocols?
How do you protect against physical threats to unattended devices/data, e.g. do you have any form of trusted boot to verify the integrity of the BIOS, bootloader and OS?
There is no protection for unattended devices lol. That's a huge cat and mouse game. It's why I used to use little embedded boxes like ARTIGO's which were easy to stash along with tamper-evidence tricks. If there was tampering, can't be trusted any more. The few times turned out to be a roommate bumbling around for some ridiculous reason.
There are many physical transports to use. My original hack was IDE in a non-DMA mode to get past serial's speed limits. Then I/O offloading onto dedicated, cheap computers to pre-process the data and force it into correct spot. Next step was synthesis of the same onto cheap, I/O-focused FPGA's or microcontrollers before I had to put a pause on those developments.
The guard [1] is the strongest part. It used simple hardware(s), a security-focused microkernel, carefully written drivers, optional middleware for internal flow control, and separate partitions for each logical function. Anything incoming is fully scrutinized before moving on. Certain protections, such as encryption, might be applied automatically. The modular, layered, often FSM-using implementation of each thing allows the highest amounts of analysis and verification w/ many errors provably absent. You can also gradually add advanced security technology as it comes online such as SecureCore, Cambrige's CHERI processor, DIFT, Softbound + CETS, etc.
So, the concept is physical separation into different domains. The computers use what they need to use. The Internet-facing ones typically did use LiveCD's and BIOS's I could protect to a degree (eg oldest boxes had jumpers). If it wasn't LiveCD, it was regularly restored from clean backups. Virtualization, hardening, and mandatory controls used as appropriate but I assume it will be toast. Simpler formats like text, HTML 3.2, BMP, and so on for easy analysis by guard. If complex stuff is allowed, it goes over a data diode so any malware isn't leaking things back.
For a similar approach at network/host level, see Boeing's OASIS Architecture [3] that builds on their high-assurance Embedded Firewall (PCI card), SNS Server (highest rating/field-use ever), and a bunch of custom components/strategies. Post-police-state, I'm basically just swapping out Linux distro's as I can't afford to build my old setups any more. My current R&D is on tools such as crash-safe.org, CHERI (w/ CHERIBSD), and the cryptographic methods that all protect system confidentiality and integrity from hardware up. Been working on verified ASIC development flow to implement them with that being done up to RTL level. Current explorations are High-level Synthesis, Analog Synthesis, and my medium-high-assurance RAD methods for software. Post most of my results on Schneier.com, etc instead of my own blog for impact with some companies copying it without credit that we've seen. I can email you those if I haven't.
[1] https://en.wikipedia.org/wiki/Guard_%28information_security%...
[2] https://en.wikipedia.org/wiki/Unidirectional_network
[3] http://www.dtic.mil/get-tr-doc/pdf?AD=ADA425566
It would be very useful if you could post some links to relevant threads about Qubes.
Couldn't find it last I Google'd for whatever reason. Could've been lost, moved, or another thing she censored. Started with a conversation on one forum where I mentioned prior work and separation kernels. A reader brought it up on QubesOS mailing list with Joanna dismissing it and cutting our comments down. So, if you're wondering about my tone, that's why. She exploded on me with ranting nonsense mixed with some useful points about her position. Went back and forth a few rounds.
Anyway, my cross-domain system saved a copy of my end of the conversation. My style is to fairly quote other person before each reply so context is obvious to readers. Anything else was ranting filler that was unimportant. You'll be able to clearly see what she was saying. Here's a Pastebin of the two logs.
http://pastebin.com/dVYcexT4
Thanks very much for that.
For what it's worth, I've found the Qubes team to be combative and defensive at times. I especially recall not managing to get straight answers about their VPN and Tor networking modules. But then, both were contributions from users, so their apparently dismissive attitude wasn't totally outrageous.
Good to know it wasn't just my own anti-charismatic personality. ;) That she didn't see the value of user-mode drivers for robustness and thought Darwin was representative of microkernel design were both disturbing in terms of "Should I trust this?" It's like they were smart on the things they published but didn't have a clue about security engineering outside of that.
So, I have no intention of ever depending on it for strong security: just maybe regular malware or containing effects of spyware, bloat, etc.
The best path to strong security has always been hardware isolation, right? So now that we have mass-market microcomputers, why bother with VMs? What do you think of Tinfoil Chat[0]? The notebook form factor could contain several microcomputers, with optical isolation, or even outright air gapping. But closed-source hardware and firmware is still problematic :(
[0] https://github.com/maqp/tfc-otp
Closed source hardware is indeed a problem: If the HW of TxM is pre-compromised, the device/malware running on it might spit out what it thinks is the key via serial or alternative covert channel.
If you start developing on top of TFC, please create a Github fork at some point and submit pull requests to any typos / issues you might find.
Not really. I started thinking that but not really sure. There's a number of models. The thing the preventative ones all have in common is they impose control on the flow of information in such as way as to prevent attacks. Separation, like address spaces, is a recurring concept and technique but not the only one. So, I use the term "information flow control" albeit it might be used differently in academia. The other model, covered by diversity and obfuscation, is to create a disconnect between what attacker envisions and what they can accomplish to create probabilistic security. The first is great against "known knowns" and "known unknowns:" specific attacks or non-specific worries in known risk areas. The second is great against straight unknowns, esp tricks nation states devise. Combining the two is most powerful and hence my recommendation. Many models of each, which further muddles things for attackers.
Far as Tinfoil Chat, I've recommended it heartily as a project to use and improve. Markus Ottela took what he learned from prior work and our comments at Schneier's blog (esp on data diodes & physical separation) to create a unique, solid design. He's been posting on the blog for feedback for months, we've suggested many risk mitigations (eg polyciphers, continuous transmission), and he's integrated about every one into his system. Most just ignore such things or make excuses: Markus is 1 in a 1,000 in (a) applying what's proven and (b) not letting problems become legacy "features."
So, yeah, I recommend it. Once my personal situation stabilizes, I plan to reimplement it with a tiny TCB on appropriate devices. I'm probably going to do a portable implementation of Send for microcontroller-style systems. Receive will be a Linux box hardened with virtualization or obfuscation security methods. Genode if it's up to it by then. The transport will be a more hardened, cheap box with just that functionality. I'm going to use CHERIBSD, if possible, just to experiment with it. Might replace the raw, serial links with MCU's or FPGA's for higher-speed, one-way I/O. Optical is highly likely (good guess). Eventually, I'm going to put it in an appliance with several, cheap boards so it's all integrated.
On my extensive backlog for now. But, yes, it's one of the best and practically has no TCB. Great design. Can be reused for email, audio, video, and maybe filesharing. Will be my interim framework until my next high-assurance system is ready.
Thanks!
It's gotten backlogged for me too. I started obsessing about potential EM coupling across optoisolators. But to test, I need a Faraday cage and gear. ...
Anyway, I'll check out the discussion on Schneier's blog.
It's kind of spread out all over the place lol. Would be difficult to even integrate. For Tinfoil, it's best to just grab the code of the Poly variety and start using/improving it. Far as the 100+ other topics, I can give you a list of links to my designs and essays there if you want to dig through for something worth building on. All I ask is credit as Nick P for whatever part my work contributes.
Thanks for the warning :)
I'd appreciate whatever links you can share. And I would be glad to credit you.
Forgot to tell you that I emailed it to your RiseUp address.