Qubes OS 3.2

Qubes OS is unlike any other desktop operating system in that it takes digital security to a much higher level than most of its competition. The extra layers of security lock down individual components through multiple virtual machines (VMs, which are also known as "qubes") that are managed by the Xen hypervisor, which makes it difficult for attackers or malicious code to compromise the entire system. Since our previous review of the first 3.0 release candidate of Qubes OS in May 2015, this brainchild of Polish security researcher Joanna Rutkowska has been revamped significantly.

Background

The initial, privileged Xen domain, Dom0, manages the other domains which, by default, consist of VMs designed solely for internet access ("sys-net" and "sys-firewall"), as well as separate "app" qubes for personal and work uses. Other default app qubes include "vault", which is isolated from the internet and designed to store data such as that from password managers, and an "untrusted" qube where any suspect devices or files can be opened.

The Qubes OS project introductory page explains that it is a form of security by compartmentalization (or security by isolation as described on the architecture page). This allows you to divide the various parts of your digital life into securely isolated qubes. By way of an example, this would mean that malware downloaded via a web browser in the "personal" qube would not be able to access sensitive data in the "work" qube. Similarly, a BadUSB device attached to the the "untrusted" qube will not be able to access any sensitive files in the other qubes.

Qubes OS uses a template system as the basis for its qubes; each VM in Qubes OS runs a copy of the template operating system. As of version 3.2, the VMs use Fedora 23 by default but can easily be switched to run Debian 8 ("Jessie") out of the box. There are also community supported templates for Whonix, Ubuntu, and Arch Linux. Qubes OS 3.2 comes with a template pre-installed for Whonix to allow anonymous web browsing through Tor. Other templates can be installed but need to be built manually from the template configuration using Qubes Builder. To save space, the template system uses a read-only root filesystem for qubes, but private data is stored in a separate block device that provides protection for the personal data from other qubes .

All of that complexity makes it easy to believe that Qubes OS is rather convoluted, but all of the qubes can be accessed from a single desktop with a GUI that runs in Xen's Dom0. The trusted window manager assigns a dedicated color frame to each qube. For instance, all "personal" qube windows are yellow by default. This also applies to panel icons so, for example, the "sys-net" VM displays a red "network connections" icon at the top right of the screen to show that it has internet access.

This setup can cause problems for users trying to connect legitimate devices. By default, only Dom0 has access to USB storage devices. The USB pass-through feature is listed as an install option but is currently experimental. This said, the Qubes VM Manager can easily be used to connect a USB storage device. Other devices such as USB webcams can be more problematic, as only one qube can access the hardware at a time. This usually doesn't pose a problem for devices such as USB keyboards and mice that will affect the machine globally. However, for security reasons the Qubes OS web site recommends setting up a VM specifically for managing USB devices.

New features in 3.2

The template VMs in Qubes OS 3.2 are based on the 4.4.14 kernel for Fedora 23. The default desktop environment has been updated to Xfce 4 but its predecessor, KDE/Plasma 5, is still supported; it also now supports the i3 tiling window manager. A new policy option for services, which will allow restricting access to specific devices, for example, has been added. A more detailed description of the updates to version 3.2 can be found in the release notes and in the project's GitHub issues.

Interested readers should pay careful attention to the minimum hardware requirements before trying to install Qubes OS 3.2. A 64-bit Intel or AMD processor is required, as is at least 4GB of RAM. The OS also requires at least 32GB of disk space. Further help for those interested in installing Qubes OS is available from the hardware compatibility list, which contains various hardware reports submitted by users over the years.

Qubes OS cannot be installed in a VM, nor will it boot from a live CD. There is a live USB version that is still in the alpha-testing stage, however. With that, only the three default application qubes (personal, work, and untrusted) will load and UEFI isn't supported. Qubes OS will install to a USB stick, provided there's at least 32GB available and the web site recommends doing so in order to boot and test the operating system's hardware compatibility on multiple machines.

The reason that the hardware should be checked so painstakingly is that some systems (especially laptops) are incapable of using Intel's VT-d (virtualization technology for directed I/O). Without VT-d, the CPU will still isolate the VMs, but their memory remains open to DMA (direct memory access) attacks via components like network devices or GPUs. The Qubes OS web site offers a helpful link to a Google Groups forum post on this topic with some useful tips on finding a compatible laptop wherein both the CPU and its chipset support VT-d.

To simplify matters even further, the Qubes OS web site maintains a web page for Qubes-certified laptops. Currently only the Purism Librem 13 is certified for Qubes OS 3.x although other hardware manufacturers are encouraged to use the Qubes OS hardware certification page to validate their own products.

Looking ahead

The same page also mentions that there are currently no certified hardware devices that meet the certification requirements for upcoming Qubes OS 4.x series. Reading through these requirements provides some insight into what the future holds for Qubes OS. In the first instance, given recent advances to CPUs and GPUs, there are plans to use nested paging (also known as SLAT or EPT) to "ditch paravirtualization (PV) technology and replace it with hardware-enforced memory virtualization".

This should help compartmentalize VMs further in the system memory, making them much less vulnerable to DMA-based attacks. This is especially important given that a security bug that exploits the paravirtualization used by Xen affected Qubes OS and was called out as a reason to move away from paravirtualization. A more in-depth explanation of this bug, named XSA-148, is available on the Qubes GitHub page.

Qubes OS 4.x certified hardware will also only run open-source boot firmware; the BIOS must be non-proprietary such as coreboot. However, the Qubes OS team has made an exception for correctly authenticated vendor supplied CPU "blobs" such as the Intel firmware support package (FSP). These blobs are software that is included by a vendor without disclosure of the source code, which makes it nearly impossible to verify they contain no bugs or hidden backdoors. Most Linux distributions (and the Qubes OS project) take a pragmatic approach to binary blobs since proprietary firmware is often necessary for some hardware to function.

In the announcement of the 4.x hardware requirements, Rutkowska clarified the project's stance on these blobs:

Examining the roadmap for Qubes OS offers a stark perspective on how vulnerable even a compartmentalized operating system can be against an adversary who can physically access a machine and install malware as part of an "Evil Maid" attack. Currently the recommend hardware requirements for Qubes OS 3.2 include machines that have a Trusted Platform Module (TPM) with BIOS support. The TPM uses a microcontroller along with encryption keys to allow trusted code to verify that a device's firmware has not been modified since the last boot, reducing the chance that a hacker could have installed spyware like a key logger.

Users whose hardware meets these requirements can install the Qubes OS Anti Evil Maid (AEM), which will display customized text or an image on the boot screen when unlocking the hard drive to reassure users that their boot loader hasn't been compromised. More information is available on AEM's GitHub page.

The Qubes OS documentation doesn't make any vaunted claims about offering a security "magic box". The security guidelines page points out, for example, that the Firefox ESR browser that is available by default in each of the application qubes is in itself no more secure than the same version of any browser on a standalone Linux machine. The only difference is the of Qubes OS architecture that keeps other data safe if stored in a separate qube.

In particular, users are encouraged not to use the main Dom0 or any of the template VMs to run applications since this would potentially affect the private areas of the "work" and "personal" qubes. The only exception to this is running updates for Dom0, which is necessary to fix the latest security bugs. The risk of opening up potentially harmful files is further reduced by offering templates for disposable VMs. If a file is found to be safe, it can then be safely copied to one of the application qubes. PDFs, which can contain malicious data, can be converted to trusted PDFs with a simple right click.

Overall, Qubes OS is a solid effort to provide usability and counterbalance the effort of juggling various VMs, while its template approach uses a minimum of resources. The truly paranoid may relish isolating the various sections of their life into separate domains. However, the elusive Holy Grail of computer security as noted in the Qubes OS own roadmap remains a device that uses both compartmentalization and entirely open-source firmware. In the meantime, Qubes OS represents one of the most solid software-only approaches to digital security.