Security challenges for the Qubes build process

>>gaius+Z7
Barely. Most of her work is behind what was done in the 80's and 90's for security kernels then 2000's for separation kernels. I criticized her for not building on proven foundations and methods. She censors my stuff but did eventually say and do some of same things. My Xen gripes, GUI trusted path... these come to mind.

For an example, here's an Orange Book A1-class VMM by legend Paul Karger. He's one of inventors of INFOSEC, genius designer/coder, and high-assurance veteran. Look at the design and assurance sections (p9 onward) of it to see what... in 90's... was necessary to secure a VMM via minimal privilege (POLA), correctness arguments, backdoor prevention, and covert channel suppression. Nothing today in OSS even has this baseline despite us discovering more problems and solutions. Re-reading it now, I noticed they were even doing continuous integration on it well before that became a fad.

http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A...

A modern example, one I cited on their mailing list, is INTEGRITY-178B. The features plus assurance activities are a nice illustration of high-assurance approach to microkernels for security or virtualization vs things like Xen. Quite a few things worth copying for security- or reliability-focused OSS projects. Approaches that got open-sourced from CompSci are in links below it.

http://www.ghs.com/products/safety_critical/integrity-do-178...

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=9EE...

http://genode-labs.com/publications/nfeske-genode-fosdem-201...

Note: GenodeOS is a competitor that uses components like above with architecture designed to lower risk in TCB like in high-assurance. It's nice work. Fundamental architecture needs peer review, though, to ensure it has claimed properties.

>>nickps+uG
I think the reason Qubes is interesting is not because it's at the forefront of theoretical security, but that it's actually useable today as a desktop. None of the systems you mentioned meet that criteria.

Using a computer today requires interoperating with such a bewildering array of other systems. Just writing a web browser is a huge undertaking.

It's wrong to compare Qubes to academic microkernels that require applications written in a formal language. It should be compared to a general Linux/BSD distro or to Windows, because those are the systems it's competing for users with. In comparison to those, it's a much more solid platform for security.

>>throwa+Yq1
You could've said same thing about Qubes in early state that you said about "academic" systems. Both just required work to get in usable shape. Far as comparisons, I do two types: compare it to mainstream OS's as you said; compare it to other systems in its category.

Now, unlike your claim, others were in production under label MILS systems far back as 2005. They used separation kernels to host VM's for Linux and Windows with networking, filesystem, GUI, etc in separate partitions plus color labels on screens. Sound familiar? Additionally, the Turaya work in Europe got turned into commercial products from Sirrix. OKL4's was deployed in a billion phones. Genode's tiny team has made theirs quite usable in short time despite all the custom work done.

So, Qubes wasn't the first, most polished, most secure, least academic, or anything. It's a latecomer using inherently bad components but with high usability and tolerance to regular malware. There's an upper limit to how much security if can provide as malware sophistication and threat model increases. So, I encourage its use only for lower, threat profiles like average user browsing the web with investments into stronger architectures for higher, risk use.

zlacker