Those who regularly follow the Black Hat briefings probably remember Joanna Rutkowska who presented a novel attack against Windows Vista (and any Operating System running on an x86 architecture, in general). She was the first researcher to demonstrate a piece of malware (bluepill) that could run in root or host mode in a current x86 architecture and push the Operating System one layer (ring) below. This technique makes the malware extremely difficult to detect (there are methods to detect that an Operating System has been virtualized, but it would be close to impossible to differentiate a Xen or VMWare hypervisor from bluepill). The name “Bluepill” is indeed quite appropriate as the operating systems (and any anti-malware protection that it could have) continues to run blissfully after taking the “blue pill“, while its integrity is compromised (“Neo… You take the blue pill and the story ends. You wake up in your bed and believe whatever you want to believe“).
A few years passed and Joanna created a company called Invisible Things Labs to develop a secure Operating System (Qubes OS) based on isolation and containment. Joanna herself commented that she doesn’t believe in antivirus and that she doesn’t run one herself. While traditional antivirus are undeniably better than nothing, due to the fact that they rely on pattern matching against known threats they are always one step behind the malware authors. Nowadays, antivirus vendors started to realize this fact and are pursuing other paradigms to improve their effectiveness (behavioral and reputation based systems, for example).
Qubes OS comes from an elegant concept: if you can isolate functional components within disposable containers, and you can separate those components that can be tainted through their interaction with the outside world from the core subsystems, you stand a good chance to preserve the integrity and security of the base Operating System at the possible expense of needing to jump through some hoops to move data around the system. All in all it sounds like a good proposition if it can be demonstrated to be practical.
In its current inception, Qubes OS is based on Fedora core 14, and uses a Xen hypervisor to provide isolation across security domains. Domain 0 is the administrative and management domain and has no networking at all (quite clever!), networking is isolated in its own domain as has a relatively high chance of getting compromised, and user applications can run in their own domains (i.e. a random browsing session running in its own domain can never compromise a secure home banking browsing session). Joanna describes in her own blog how she partitions her digital life across multiple security domains as an example of a possible layout.
The selection of Xen over KVM/Qemu obeys to the fact that it would be very hard to security proof the entire linux kernel and associated utilities to prevent any “leakage” or compromise across virtualized containers, but the codebase for Xen is quite compact and easy to audit.
The current version of Qubes OS is Beta 1 and was released last March. While it’s far from being ready for general consumption (I have tried it in a couple of systems and got it to different running stages, but none of them could be really considered ready for general use), it provides for a good showcase of what this technology is capable of. Essentially, the user logs into a graphical environment, can set up different security domains based on an existing template (provided by the system) and label them with colors indicating their security/trust level (from red to black). Regardless of the color, the security domains are isolated among each other.
As it stands now, Qubes OS can run only Linux applications, but there is nothing inherently preventing it from running MS Windows applications (probably a must for adoption in corporate environments) so this could be a feature expected to come up in future releases. In addition to this, data flows in Qubes OS seem to be currently loosely defined or discretionary at best (it is up to the user to move data among domains and there are no hard rules of what can and cannot be accessed and/or copied to/from different level security domains). One could expect some sort of mandatory access control that could help implement some of the formal security models (Bell-LaPadula, Biba, Clark-Wilson, etc.) to appear in future releases, in order to foster Corporate and possibly Government adoption, particularly in multi-user environments.
From a security standpoint, of course Qubes OS is still susceptible to attacks, and the most radical being Bluepill itself, which could be preventing by resorting to Intel Trusted Execution Technology (TXT). Traditional malware, albeit not as frequent in Linux environments, could exploit the exposed security domains, but this should not lead to the compromise of the integrity of the entire system thanks to the isolation among domains. And, of course, attacks to the user (social engineering or otherwise) are still effective as only a discretionary security model is implemented in Qubes as of today.
All in all, Qubes OS is a new and refreshing approach to system security. It is based on a few sound and well proven security principles: concise and auditable code at the core/hypervisor, containment and isolation at the heart (a compromised domain can be disposed of without affecting the integrity of the complete system) and an intuitive graphical interface to allow users to model the segmentation based on their needs. Where it still falls short is in its ability to protect the users from themselves, and history has proven maybe too well that end users can be their worst enemies.