No matter how good the code review process is, or how high the standards for acceptance, applications will always have bugs, says Joanna Rutkowska, founder and CEO of Invisible Things Lab. So will drivers. And filesystems.
“Nobody, not even Google Security Team, can find and patch all those bugs in all the desktop apps we all use,” Rutkowska says in the Q&A interview, below.
This is why she and her team built Qubes OS, a security-focused open source operating system based on Fedora that, in essence, assumes that bugs are everywhere. Instead of running one kernel, Qubes isolates all functions into separate virtual machines using the Xen hypervisor. Each function may only access what it needs to run, thus limiting an exploit’s potential damage.
Rutkowska will give a keynote talk about Linux security and Qubes OS at LinuxCon and CloudOpen Europe, Oct. 13-15 in Dusseldorf, Germany. Here she gives an overview of the project, how it uses Xen, and how it addresses common security issues.
Linux.com: What is Qubes OS?
Joanna Rutkowska: Qubes OS is an open-source operating system designed to provide strong security for desktop computing. Qubes OS implements security by a compartmentalization approach. It’s based on Xen and Linux, but also has support for Windows-based AppVMs.
How does it use the Xen hypervisor and Linux?
Qubes uses Xen as a “compartmentalization provider.” We believe Xen is very powerful for this role. The Xen hypervisor is (still) relatively bloatware-free and had a decent architecture that allows us to keep it reasonably secure (e.g. it allows to keep qemu outside the TCB). It also offers support for so-called driver domains, which Qubes utilizes to sandbox networking and USB stacks.
Having said that, it is important to remember that Qubes is largely independent of the underlying hypervisor. In the next release (R3) we’re even introducing a Hypervisor Abstraction Layer to allow for (relatively) easy swapping of Xen for other VMMs. So, in the future we might see e.g. a KVM-based variant of Qubes OS, for better hardware compatibility.
Qubes uses Linux (here I mean both the kernel and the platform) mostly as an… “API provider” for apps and drivers. We don’t utilize the security mechanisms Linux provides, and instead we rely on Xen isolation for that.
This statement might sound like downplaying the importance of Linux, which, however is not my intention. There would be no Qubes OS without the flexibility of Linux. Even though we now also have support for Windows-based AppVMs, Linux is still unbeatable when it comes to making lightweight user AppVMs and sophisticated service VMs, or fueling Dom0 — the admin domain of Qubes OS.
What are the main security issues that you’re trying to address?
That desktop applications do have, and always will have, bugs and we need to accept the fact that nobody, not even Google Security Team, can find and patch all those bugs in all the desktop apps we all use.
That desktop drivers for various devices (WiFi, USB, etc) do have, and always will have bugs. That various more or less exotic filesystem implementations do, and always will have bugs. Etc.
How does Qubes address those issues?
Unlike other approaches which try to add security mechanisms to the already bloated kernels or systems, Qubes takes a different approach: it starts with a bunch of well-isolated compartments (Xen VMs), which represent various user security domains and system service VMs, and then, very carefully, builds bridges across those isolated compartments.
These “bridges” are essential to make Qubes actually usable as a desktop system, and include things such as seamless desktop GUI virtualization, secure copy-and-paste and file copy between different domains, and many other services. Clever use of these inter-VM bridges allows, in some cases, to actually achieve better overall security than in case one used multiple physically separated computers — you can read more on this surprising effect in this recent paper:
Can you tell us more about what you plan to talk about at LinuxCon and CloudOpen Europe?
I will have a short keynote about why we do Qubes OS and what does our upcoming roadmap looks like, and then we plan to have a more in-depth two-hour session on Qubes for more power users and developers.
application embedding instead of attempting to create a new one.