Qubes VS Nova microhypervisor VS LynxSecure
Nick
"Nick seemed rather knowledgeable" (PH.T.)
"please, for Christ's sake, don't refer to blog *comments*!" (Joanna)
I would hope so, PH.T. Clive Robinson ("main of many brains") and I have been hammering at this problem for about a year or two now on Schneier's blog (Google our names and Schneier's for thorough discussions) and I have over 200 papers on high assurane designs I've skimmed so far. I'm always looking for new and old approaches to bulletproof systems. And quoting comments is a good idea if they contain high quality information, which I'll leave others to decide with regard to mine. I don't maintain a blog at the moment. I comment mainly on Krebs on Security and Schneier on Security about the security of OS's, crypto, applications and systems in general. I would [sadly] say that the comments on Schneier's blog are usually of higher quality than many IT blogs... (Although Joanna's advice is appropriate for *those* blogs ;)
@ Joanna
"It's a mistake to compare Qubes to some hypervisor projects..." (Joanna)
I could certainly have worded my post better, as it was hastily typed on someone else's PC. My comparison was to other projects with the same goals as I read of QubesOS in various press releases. These projects not only had similar goals, but also often had similar functionality already finished (or deployed in real world). I'll post examples for clarification.
"I'm not aware of any project that could be even compared to Qubes -- if you know, please let me know..." (Joanna)
"Qubes project focuses on things such as: secure GUI isolation, driver/backend sandboxing, trusted boot, and hiding all the inconveniences above from the user..." (Joanna)
A number of projects I mentioned have similar focus, aspirations and sometimes existing feature set. Here's a few.
Green Hill's INTEGRITY Desktop: military-grade secure kernel, trusted path GUI with secure attenuation sequence, high assurance networking stack, driver isolation, deprivileged virtual machine monitor, Windows/Linux/POSIX support, ability to run native programs beside virtual machines, TPM/TXT support, and high assurance cross domain transfers between VM's. It's been available since 2005 and is my gold standard for measuring open source alternatives.
TU Dresden's L4-related work in 2006 produced Nizza Architecture, allowing security-critical apps to run side-by-side with apps in a legacy OS VM. Demoed by GPLed TUD:OS, it had an minimal-TCB GUI, deprivileged Linux VM, scheme to run Linux-compatible device drivers isolated as apps on microkernel, a virtual filesystem, Qt3 toolkit, libSDL toolkit, and an ecommerce transaction demo that shows the simplicity of the system. Nizza was later used to create Micro-SINA, a low TCB IPSec VPN.
Perseus Security Architecture, designed in 2001 and implemented mostly by 2005, was Europe's scheme. The resulting Turaya Security Kernel platform was released under GPL and provides: microkernel; secure storage for keys; TPM booting; isolated apps; isolated drivers; VM for legacy Linux apps & untrusted code. The Turaya Security Platform is being applied in a secure phone by OK Labs & Sirrix, VPN, and drive encryption. First application was Turaya Desktop w/ TPM/kernel-protected disk encryption, VPN, and DLP features.
OK Labs and NICTA. They created L4 & OKL4 kernels, deprivileged Linux layer, isolated Linux-compatible device driver scheme, ultra-fast isolated apps on microkernel, and capability based security. It was licensed open-source for non-commercial use and pretty cheap for commercial use. Recently, a formally verified microkernel (seL4/OKL4 Verified) with the above features was released. Field tested in 1 billion phones.
These are my main comparisons and I contend they are quite similar to what the QubesOS team built in many respects, but their base platform is superior. The main superiority is that microkernel's can run isolated apps much better than the Xen kernel, a derivitive of the Nemesis microkernel designed primarily to run VM's, clunky for isolated app execution, and not designed with security baked-in from start. The more isolated nature of the drivers in these other projects, along with Linux driver reuse, already made one of your goals easy w/out having to contend with the dom0 problem Xen had.
Now, all that said, I definitely like your project. You've accomplished a lot and developed plenty of great features. My criticism was that applying the same amount of effort to one of the above existing projects would have resulted in a platform with better features, more assurance, a base more amenable to high assurance methods, and probably higher performance if a microkernel like OKL4 was used. Again, though, even if researchers disagree where to put their efforts, I'm glad to see another useful way to improve the security of the average user's desktop and I love the quality of Invisible Things' work. My mind has even been turning over the idea of integrating your team's work with one of these other systems.
To be honest, my biggest disappointment was personal and unrelated to the results of the QubesOS project. I had been following Invisible Things work on vulnerabilities in hardware, firmware, etc. for a while. You all simply did awesome work. The types of vulnerabilities found were well-known in academic circles: papers written at the time of the Orange Book showed x86 for the insecure, hard to virtualize and covert channel-ridden mess it was. Your team demonstrated these theoretical findings perfectly & made the public aware.
So, here we were, working on designs building on top of projects like Perseus. Trusted boot, trusted path, secure storage, isolation, etc. were mostly solved problems, esp. with the separation kernels. The remaining problem was untrustworthy hardware/firmware/BIOS undermining all of the above (including Qubes to a degree). I was hoping Invisible Things' next move was solving that problem somehow so that our existing software could work w/out worries. Then, we got another secure virtualized desktop platform running on buggy x86, admittedly with some nice new features.
Idk. I guess I was just hoping the best hardware hackers would give us better hardware assurance profile, if only a proposed design. Fortunately, Rockwell-Collins AAMP7G processor, the VAMP processor project, Aegis secure processor, and Secure Core project gave us (or are giving us) something to work with. Again, it was just a personal hope that the lab's expertise would solve the one remaining problem for even the most basic secure x86 system: untrustworthy hardware, microcode, firmware, BIOS, etc. The problem still exists, effort was duplicated and only Secure Core provides hope that x86 SOC assurance can be improved. Until then, it's the weakest link in even the best kernelized system.
Your team was the only well-known team that I thought could do the job since you lived and breathed hardware flaws. Now we just have a few obscure groups with less pentesting experience trying to solve the problem. It's the most neglected area of INFOSEC. With each security layer depending on the one before it, this is also the most important part of a secure system design. Few designs provide high assurance of trustworthy hardware and firmware operation. We need more efforts in this area. More teams with Invisible Labs expertise hitting the oldest unsolved problem in secure computing: the layer below the OS.
Joanna Rutkowska
> A number of projects I mentioned have similar focus, aspirations and
> sometimes existing feature set. Here's a few.
>
> Green Hill's INTEGRITY Desktop: military-grade secure kernel, trusted path
> GUI with secure attenuation sequence, high assurance networking stack,
> driver isolation, deprivileged virtual machine monitor, Windows/Linux/POSIX
> support, ability to run native programs beside virtual machines, TPM/TXT
> support, and high assurance cross domain transfers between VM's. It's been
> available since 2005 and is my gold standard for measuring open source
> alternatives.
>
If you could get me a running copy of GH's OS onto my desktop, then I
could comment on this product. Or, at the very least, the architecture
documentation for their mysterious product. Interestingly I have
requested a copy of the documentation through their website more than a
year ago and they never got back to me... (Hey GH!) So, I consider this
product essentially a vaporware. I will change my mind when I will be
able to download at least a trial ISO from their website and try by
myself...
> TU Dresden's L4-related work in 2006 produced Nizza Architecture, allowing
> security-critical apps to run side-by-side with apps in a legacy OS VM.
> Demoed by GPLed TUD:OS, it had an minimal-TCB GUI, deprivileged Linux VM,
> scheme to run Linux-compatible device drivers isolated as apps on
> microkernel, a virtual filesystem, Qt3 toolkit, libSDL toolkit, and an
> ecommerce transaction demo that shows the simplicity of the system. Nizza
> was later used to create Micro-SINA, a low TCB IPSec VPN.
>
Where can I got an install-able & usable distribution/OS based on this
concept?
> Perseus Security Architecture, designed in 2001 and implemented mostly by
> 2005, was Europe's scheme. The resulting Turaya Security Kernel platform was
> released under GPL and provides: microkernel; secure storage for keys; TPM
> booting; isolated apps; isolated drivers; VM for legacy Linux apps &
> untrusted code. The Turaya Security Platform is being applied in a secure
> phone by OK Labs & Sirrix, VPN, and drive encryption. First application was
> Turaya Desktop w/ TPM/kernel-protected disk encryption, VPN, and DLP
> features.
>
Where can I got an install-able & usable distribution/OS based on this
concept?
> OK Labs and NICTA. They created L4 & OKL4 kernels, deprivileged Linux layer,
> isolated Linux-compatible device driver scheme, ultra-fast isolated apps on
> microkernel, and capability based security. It was licensed open-source for
> non-commercial use and pretty cheap for commercial use. Recently, a formally
> verified microkernel (seL4/OKL4 Verified) with the above features was
> released. Field tested in 1 billion phones.
>
Yeah, and we all see how secure the mobile phones are these days...
Superior security indeed ;)
<even more ironic>
I'm surprised you never mentioned the secure-by-design
_micro-kernel-based_ Max OS X?! ;)
</>
> These are my main comparisons and I contend they are quite similar to what
> the QubesOS team built in many respects, but their base platform is
> superior. The main superiority is that microkernel's can run isolated apps
> much better than the Xen kernel, /.../
Please support this statement with concrete arguments.
> The more isolated nature of the
> drivers in these other projects,
You clearly don't know what are you talking about here...
> along with Linux driver reuse, already made
> one of your goals easy w/out having to contend with the dom0 problem Xen
> had.
You clearly don't know what are you talking about here...
>
> Now, all that said, I definitely like your project. You've accomplished a
> lot and developed plenty of great features. My criticism was that applying
> the same amount of effort to one of the above existing projects would have
> resulted in a platform with better features, more assurance, a base more
> amenable to high assurance methods, and probably higher performance if a
> microkernel like OKL4 was used.
Why? Give concrete arguments, pls. Oh, and don't forget that we want
features such as power management in Qubes! And we want to support x86.
> To be honest, my biggest disappointment was personal and unrelated to the
> results of the QubesOS project. I had been following Invisible Things work
> on vulnerabilities in hardware, firmware, etc. for a while. You all simply
> did awesome work. The types of vulnerabilities found were well-known in
> academic circles: papers written at the time of the Orange Book showed x86
> for the insecure, hard to virtualize and covert channel-ridden mess it was.
Yup, our algorithm for coming up with new research: take an academic
paper from the 80's, and rewrite it adding funny jokes, publish. You got us!
> Your team demonstrated these theoretical findings perfectly & made the
> public aware.
>
> So, here we were, working on designs building on top of projects like
> Perseus. Trusted boot, trusted path, secure storage, isolation, etc. were
> mostly solved problems, esp. with the separation kernels.
You clearly confuse terms -- separation kernels have nothing to do with
trusted boot -- these are orthogonal things.
> The remaining
> problem was untrustworthy hardware/firmware/BIOS undermining all of the
> above (including Qubes to a degree).
That's mostly covered by trusted boot technologies (which itself have
bugs, of course, as we already domed twice).
Cheers,
joanna.