Qubes, a Linux OS, uses Xen to spawn multiple domains and promises to reduce risk with some extra effort. For most of us, the effort would be better spent elsewhere

InfoWorld|Jan 7, 2014

A reader recently wrote me to ask how I felt about Qubes, an operating system conceptualized and co-created by Joanna Rutkowska, founder and CEO of Invisible Things Lab.

Qubes is a Fedora-based Linux OS running on Xen, a bare-metal hypervisor. Qubes' most interesting feature is the ability to run one or more security domains, each of which operates in a separate, lightweight virtual machine environment. The idea is to provide a more secure OS in which it's highly difficult for one exploited app or environment to impact apps or environments that reside in different security domains.

Just about anything Rutkowska conceptualizes or discusses related to computer security is great stuff. She sees things other people don't and stimulates interesting discussion. She is best known for her provocative Blue Pill, a hard-to-detect rootkit that relies on virtualization. Rutkowska formally presented Blue Pill at a 2006 Black Hat conference, stirring controversy that lasted for years.

When considering Qubes, two questions emerge: Is Qubes more secure than other "more secure" operating systems, such as OpenBSD? And do we really need another "more secure" OS? I can't knowledgeably comment on the former because I haven't installed it, reviewed its source code, or done formal threat modeling. Lucky for you, that won't stop me from postulating.

Stay out of my sandbox

In theory, security domain isolation is a good thing. It's the basis of many security controls, including access control lists, firewalls, and authentication. But in practice, strong security domain isolation is very difficult to achieve. In a nutshell, the stricter the security domain, the less usable the feature.

With real-life, usable operating systems, applications running on the same computer have to interact all the time and save their state over multiple sessions. In Qubes, you can have one or more applications running in the same security domain or in separate domains, depending on your needs. I have no doubt that Qubes does this well. The problem is with users correctly determining what applications need to talk to each other -- as well as which need to save data and state for future sessions. It's also a challenge to determine quickly whether a security domain has been compromised. I first wrote about these conundrums in 2008 when discussing red/green computing and the use of virtualization for security domains.

Isolated ... or not?

Here's a good example of a potential problem: Suppose I run my Internet browsing in one domain, my email in another, and my supersecure corporate applications in another.

At first, it looks pretty good. Internet browsing is very high risk, so it needs its own security domain. If my browser is exploited, the agent can't jump to my other domains. But how do we treat work-related, HTML-enabled content sent by one corporate employee to another? Normally you'd transmit it via email or maybe a chat or social media message. When you click to open it, it's handed off to a browser in most cases. While that could be to a more secure browser instance, what if that content needs to be fed or copied to a corporate system? There will be times when you need to cross security domains.

Sure, you can run a VM that contains only the browser, email, and corporate data systems required for work. But that means you should never receive any personal emails to your work email system. This sounds great, but you can already do that without the additional security domain separation. If you opened only work-related email and visited only company-related websites, you wouldn't need separate domains in the first place.