Moving toward Qubes OS 4.1

On October 11, the first release candidate for Qubes OS version 4.1 was announced. Qubes OS is a security-oriented desktop operating system that uses multiple virtual machines (VMs or "qubes") to isolate various types of functionality. The idea is to compartmentalize different applications and operating-system subsystems to protect them from each other and to limit access to the user's data if an application is compromised. Version 4.1 will bring several important enhancements to help Qubes OS continue to live up to its motto: "A reasonably secure operating system".

It has been nearly five years since we looked at Qubes OS 3.2, though we have checked in on it a few times since we first wrote about it back in 2010. As with much in the security world, there are tradeoffs to be made when using Qubes OS, but it provides a level of security that is hard to find elsewhere. In addition, it does so using Linux and other open-source tools, so that users can inspect and modify the system as needed.

Moving the GUI out

Qubes OS uses the Xen hypervisor and an ever-growing set of qubes to isolate various pieces. The Xen Dom0 top-level domain, which runs the host operating system, is the most privileged part of the system after the hypervisor. It provides the administrative interface for the system as a whole, but also acts as the display manager for all of the qubes. For one thing, being in control of the display manager allows Qubes OS to enforce colors on window borders to indicate which qube they belong to. One of the headline features of Qubes OS 4.1 is splitting out the display handling into a separate GUI domain.

There are multiple reasons for separating out the GUI, but reducing the functionality in Dom0 is one of the primary motivations:

One of the biggest security concerns at the moment for Qubes is how much power is in dom0. Once a person has access to it, they can do anything: and while we separate it quite effectively from what is running inside application qubes, dom0 is still a big, bloated and complex domain that performs many disparate functions. It handles managing other domains, display and graphical interfaces, multiple devices (including audio devices), memory and disk management, and so on.

Qubes OS already has a GUI protocol that is used to compartmentalize the graphics handling: "Applications in VMs can't talk to GUI toolkits in dom0 other than through a very limited Qubes-GUI protocol, and GUI toolkits in application VMs can't talk directly to dom0's X server." But that mechanism requires Dom0 to directly map the memory of the qubes for window buffers, which is worrisome. Duplicating that ability in a separate domain would effectively result in having two Dom0s, thus increase the attack surface.

In version 4.1, the protocol has been changed so that the GUI handling does not require the ability to reach into arbitrary application qube memory. It uses "an abstract mechanism in which the qube has to explicitly allow access to a particular memory page". There is a concrete implementation for Xen (using the grant table mechanism), but other mechanisms could be used for other environments (e.g. KVM).

Beyond the memory handling, the existing graphics handling relied on the ability of Dom0 to control any of the qubes; a less-privileged GUI domain still needs to be able to do that, but in restricted manner.

But if we want to implement a more contained and less-privileged GUI domain, it would defeat part of its purpose to just permit it to run any sort of qvm-run do-what-I-want in any of the managed qubes. Qubes 4.0 introduces a special qubes.StartApp qrexec service that runs only applications defined inside the target qube (currently defined via .desktop files in Linux and .lnk files in Windows, placed in predetermined directories). This mechanism allows a qube to explicitly define "what the GUI domain can execute inside me," and not just hand over all the power to the managing domain.

The new GUI domain is an experimental feature for Qubes OS 4.1. As is noted in the future plans section of the lengthy blog post describing the feature, it is taking the system further in the direction laid out in the original Qubes architecture specification—from 2010.

Qrexec

Another large piece of new functionality for Qubes OS 4.1 is improvements to the qrexec facility and its policy handling. Qrexec provides a remote procedure call (RPC) mechanism for inter-qube requests, but, obviously, there need to be limits on what can be requested:

Of course, allowing everything all the time would be extremely dangerous. Thus, a part of qrexec called "qrexec policy" is also used to enforce who can do what and where. Furthermore, we want to be able to audit what was done, and this is provided with the logging capabilities of qrexec. The how is controlled by qrexec services, which are executed by qrexec and also must be designed in a secure and resilient way.

That detailed blog post describes several areas where qrexec has been upgraded for 4.1, starting with changes to the policy format itself. The Qubes OS 4.0 policy format, which will continue to be supported, split the policies up by the service they applied to, leading to dozens of separate files.

Under the new format, the policy for a single qube is much easier to find, parse, and edit. [...] For example, it's trivial now to forbid all calls for a given qube or forbid all with a list of exceptions. This allows for a more qube-centric approach to policies, and while the results are theoretically the same, there's a huge difference between a couple of rules, all in one [place], and dozens of rules spread across dozens of files.

In addition, the policy system is designed to "fail closed"; any syntax errors or other problems in the policy files will result in no permissions being granted by the qube. This is similar to the behavior of sudo and other security-focused tools.

The performance of qrexec has also been improved substantially for this release. Data is now transferred in much larger chunks (64KB rather than 4KB), which helps speed up large data transfers. In addition, there is a new policy daemon, rather than starting and loading a policy-handling process for each qrexec request. That cuts down the initialization time, which is important for repeated calls.

Reproducibility

In order to be sure that a particular binary has been created from the source code that it is purported to come from, there needs to be a way to reliably reproduce a binary from the source. That is what the Reproducible Builds project is all about. The Qubes project has been working on incorporating reproducible builds into its continuous integration (CI) infrastructure.

In particular, the current goal is to be able to build the Qubes OS Debian templates solely from packages that can be built reproducibly. Templates in Qubes OS are VM images that can be used to start an application qube quickly based on the template. The qube will have read-only access to the root filesystem of the template, so that the same root filesystem can be shared with multiple application qubes. There are official templates for several variants of both Fedora and Debian, as well as community maintained templates for several other distributions.

Debian has been at the forefront of reproducible builds for some time now, so it is no surprise that is where Qubes OS is focusing its current reproducible-building efforts. But Qubes ran into some problems retrieving older versions of Debian packages from the snapshot.debian.org service, which is known to have limitations that make it less that fully reliable for this purpose. That led the project to build its own snapshot service and rebuild Debian packages using it.

As of early October, 80% of the Debian unstable repository has been successfully rebuilt. The process was restarted for the Debian 11 ("bullseye") repository, which still has "a couple thousand package rebuilds remaining". Once that is done, the rebuilding of unstable will be completed. This is all being done on several servers hosted at home by Frédéric Pierret.

The next goal is to have the Debian templates reject the installation of any packages that cannot be verified as having come from the source code claimed. There is also work being done to add Fedora into the mix. It is notable that the Reproducible Builds project is using the results being reported for Qubes OS as "an example of what it has been advocating for years".

And more

There are other features coming in the release, of course, as well as lots more details on the pieces we looked at above. The release notes have a longer list of new features, which links to the closed issues for the release at the project's GitHub repository. As might be guessed, there is a long list of bug fixes made for 4.1 as well.

The last major version of Qubes OS, 4.0, was released in 2018. A half-year later, project founder Joanna Rutkowska stepped down from her leadership role in order to work on other projects. That kind of change can be highly disruptive, but the project seems to have come out of it just fine. There have been several minor releases over the intervening time—the most recent was Qubes OS 4.0.4 back in March—as well as a continuing stream of updates to address Qubes security bulletins.

According to the announcement, the second release candidate will come in "a few weeks to a few months" depending on the number and severity of the bugs that are found. If we use the 4.0 release as a guide, we can perhaps expect five release candidates over eight months before a final release of 4.1. More testing and fixing would likely speed the whole process up, of course, but a late (northern hemisphere) spring or early summer final release seems like a reasonable guess at this point.