Qubes OS nears version 3.0

It has been just over five years since we last looked at the security-focused Qubes operating system (or Qubes OS). Back then, Qubes OS was brand new and version 1.0 was still in alpha, but the OS is now fairly well established, with version 3.0 slated for release in the next few months. The first release candidate for Qubes 3.0 was released at the end of April, along with a roadmap that shows where the project plans to go over the next year or so.

Qubes uses the Xen hypervisor, coupled with multiple virtual machines (VMs) typically running Linux, to provide separation—compartmentalization—between applications and between parts of the OS itself. Users are able to run specific sets of applications in a named security domain. Each domain is in its own VM; user-defined domains are called AppVMs in Qubes. That can limit the damage that malware can cause if it compromises a particular instance of, say, the web browser. By putting the browser and email client for work in one AppVM, and those for personal use in another, Qubes makes it hard or impossible for vulnerabilities in one AppVM to be used attack the other—or the overall OS itself.

A Qubes system consists of several SystemVMs that handle various parts of what would normally be kernel functionality. There are separate SystemVMs for networking, storage, and the graphical user interface (GUI). The idea is that compromising the network domain does not directly lead to a compromise of the system's storage and vice versa. In a normal Linux system, vulnerabilities in the network or storage subsystems would allow access to another kernel subsystem, but that is not true for Qubes. By using Intel's virtualization technology for directed I/O (VT-d), the storage and network domains can have direct memory access (DMA) capabilities for the hardware and memory assigned to them, but not be able to use DMA to access memory or hardware in the rest of the system.

The GUI domain runs in Xen's Dom0 (i.e. the "host" domain), so it is effectively the master VM for the system. It provides the administrative interface for the system, so it is also referred to as the administrative domain. It has access to the graphics and input hardware and runs the X server that provides the user's desktop. It does not run the user's applications, as those are run from the AppVMs using an Application Viewer that gives the illusion that the application is running in the GUI domain, when it is really running in a separate VM. To make that work, an X server in the AppVM uses Xen's shared memory to communicate to the X server in the GUI domain, which displays the program's output.

Obviously, any of the VMs that need to access storage or networking will need to get that access from the appropriate domain. The network domain provides virtual Ethernet devices to each of the AppVMs, but not to the GUI domain, which has no networking code. But the Dom0 GUI domain does need access to storage, which is provided by the storage domain using Xen's block backend to create virtual block devices for each VM. Each VM encrypts its data with its own key that is not known to the storage domain (only to the VM and the administrative domain), so even a compromise of the storage domain does not give access to the per-VM private data. In addition, Qubes OS uses a verified boot process that employs the Trusted Platform Module (TPM) hardware and Intel's Trusted Execution Technology (TXT) to ensure that the hypervisor and Dom0 code have not been tampered with.

That overall architecture of Qubes is largely unchanged since our 2010 article and is described well in the Qubes OS architecture document [PDF]. In fact, there is a wealth of information on the Qubes web site, starting from the documentation page, which is split into user and developer documentation. Qubes is mostly available under the GPLv2, though some components have their own open-source licenses. In addition, Invisible Things Lab (ITL), which has been the primary developer of Qubes, requires permission to relicense contributions under other, potentially proprietary, licenses. Interestingly, there does not appear to be a contributor license agreement or other document involved; the "Signed-off-by" line is used to indicate consent with that policy.

Qubes founder Joanna Rutkowska announced Qubes OS 3.0-rc1 on her blog. She also described the steps that the project is undertaking to protect itself from targeted attacks against its code. In addition, it is working on eventually being able to provide reproducible builds so that users can ensure that the code distributed is the same as what is built into the Qubes binaries. Lots of progress has been made in protecting the templates, which are based on various Linux distributions and are used to build the VMs. Reproducible builds are a harder nut to crack, as we have noted a few different times; it is good to see Qubes tackling the problem.

The headline feature for the 3.0 release is the hypervisor abstraction layer (called the HAL). It will allow Qubes to use hypervisors other than Xen by using the libvirt virtualization API. The target for the feature appears to be Windows virtualization to better support that OS in Qubes.

In general, it would seem that much of the work in the intervening years since the original release has been targeted at making other operating systems—mostly Windows, but also various BSDs—work with Qubes. The new features listed in the various 2.0 release announcements (from beta 1 in December 2012, through beta 3 in December 2013, to the final 2.0 release in September 2014) highlighted the Windows work. It should be noted that the Qubes core code is open source, but the Windows pieces are only available under a proprietary license from ITL. The other new features along the way have mostly been upgrades to various underlying packages or templates, like Xen, X.Org, Fedora, Debian, KDE, Xfce, the Linux kernel for Dom0, and so on.

Trying out Qubes OS 3.0 will be harder than it is for most distributions as there is no "live CD" version available. Running it in a VM is, unsurprisingly, not supported either. Finding real hardware that supports VT-d and installing it seems to be the only way to get a taste. Perhaps that will be something to try when the full 3.0 release is made in a few months.

Rutkowska's announcement also came with a roadmap (complete with a diagram showing the features and dependencies) for releases in the 3.x series (up through 3.3 due in 2016) and the 4.x series (coming in late 2015). It looks like a rather ambitious schedule, but one that leads to reproducible builds for Qubes. Other items include things like GPU pass-through, so that AppVMs have access to the GPU for accelerated graphics, UEFI boot support, and an out-of-the-box Tor setup.

Qubes OS is an interesting idea. It embodies the idea of "security by isolation", which is the only approach to security that is likely to succeed according to a Qubes FAQ entry:

The OS is also a demonstration of the innovative tools that can be built atop an open-source base. As Rutkowska noted in the 2.0 release announcement, Qubes OS would not have come about without "all the upstream projects without which we would probably never even try this journey: Xen, Linux, Xorg, and many others". For those who are highly security conscious—or concerned about state-level or targeted attacks—Qubes may well provide a "secure enough" computing environment. For the rest of us, it may be overkill, but it is certainly worth a look.