Compartmentalization has always been a basic principle of security. For instance, limiting what can be done with a regular user account confines the damage that can be done by malware to the current user account. However, Qubes OS [1] takes compartmentalization to an extreme, running each window in its own Xen hypervisor [2]. The result is one of the most innovative desktop environments available, as well as what the project understatedly calls a "reasonably secure operating system."

Qubes is not the first distribution to emphasize security. A popular practice is to sandbox [3] questionable applications, often running them in virtual machines. In the last few years, the security-focused Tails [4] distribution has also become popular. However, as the Qubes documentation points out, virtual machines are only as secure as the host operating system. Similarly, Tails, while providing a strong measure of security, because it is designed to be run off a flash drive, is still monolithic, which means that if any part of it is cracked, the whole system is likely to be as well.

As for anti-virus applications and firewalls, they are at best a partial solution, because malware today is often concealed in legitimate applications. By contrast, so-called "bare metal" hypervisors like Xen do not run from the host operating system, making them more difficult to crack, whereas compartmentalization limits any potential damage and makes Qubes highly customizable as well.

As you might expect, this level of security puts high demands on hardware [5]. Running only on 64-bit machines, Qubes requires 4MB of RAM to run and 32GB of disk space, and the installation images vary from 2.3 to 3.5GB. Additionally, you should check the hardware compatibility list [6] before installing, because, so far, Qubes runs on only a limited number of processors. Nor is Qubes designed for virtual machines, although a few users have reported managing to run it on one.

Qubes can be viewed and installed in several ways. A Live DVD is currently in alpha release, and release candidates for installation are also available. Using a version of Fedora's Anaconda installer, users can install Qubes to either a hard drive or to a flash drive, which gives an extra measure of security, as for the Tails distribution. Be aware, however, that the installation images do not support VFAT, the usual filesystem for flash drives, so any flash drive might need to be reformatted before being used. By default, the installation image also encrypts the destination drive.

All these considerations mean that users cannot assume that they will have a straightforward installation without some preparation. However, they can ease the process by reading the installation guide [7]. Once all the difficulties are overcome, a Qubes installation boots into a Debian-based system with an option of KDE or Xfce desktop environments. The applications are standard, but what stands out is the extra level of security that Qubes, which occupies 16GB, adds compared with a standard Debian's [8] suggested minimum of 10GB.

Understanding Security Domains (AppVMs)

Before using Qubes, users should read its online introduction [9] and getting started guide [10] to get a sense of its concepts and how to use them.

Qubes is based on security domains, or AppVMs (Application Virtual Machines), each of which has a different level of security. Settings for each domain is defined in a template, a copy of which can be use to run any application. By default, Qubes installs with three domains – work, personal, and untrusted – although users have the option of adding, deleting, or editing domains, either through the VM Manager (Figure 1) or from the command line. Once defined, applications can be started from the menu, where they are grouped under the security domain to which they have been assigned (Figure 2).

Figure 1: Qubes runs a series of virtual machines, each with its own security levels. (All screenshots from Quebes-OS.org, with permission.)

Figure 2: Qubes' domains are listed in the menu, with the applications that are open in the domain listed in the submenus.

To help distinguish domains, each has a color-coded border around its window (Figure 3). For example, fully isolated domains might have a green border, less secure domains a yellow one, and completely untrusted domains a red border, providing simple and immediate visual cues to each domain's level of security. Users can also run two instances of a program under different domains, such as a fully isolated copy of a web browser and a more relaxed copy for ordinary browsing.

Figure 3: Each security domain has a color-coded window border, making it identifiable at a glance. Here, three different domains are in use.

Qubes also has a fourth domain, dom0, from which the Desktop Manager runs. For security reasons, dom0 has no network connection and exists only to launch windows and manage domains, using four basic commands: qvm-create, qvm-remove, qvm-ls, and qvm-run. Technically, applications can be launched in dom0, but to do so would be comparable to browsing the web while logged in as root – it would undermine the entire security of the system.

As users explore Qubes, they will notice that none of the windows can be open in full-screen mode. According to Qubes documentation, this default is set to prevent applications emulating the entire system. However, such emulation does not happen with the KDE overview or Alt+Tab switching in Xfce, so users can enable full-screen mode by changing the allow_fullscreen field in either the global section or the section of a specific app to true.

Besides the basic security domains, Qubes also uses what it calls Disposable VMs [11] to increase the security of basic tasks. For example, to read a PDF file downloaded from the Internet, users click the file and select the option to open in a Disposable VM (Figure 4). Once the PDF is closed, the Disposable VM is simply deleted. In this way, security domains keep even quick, temporary tasks isolated from each other.

Figure 4: Tasks such as opening a file in a viewer are done in a Disposable VM, that only exists until it is closed.

Taking Extra Steps

Qubes' security domains are rigidly enforced. Consequently, many routine operations require extra steps. For example, copying text snippets or files from one application to another in a different domain is not just a matter of copying and pasting while changing windows. Instead, between copying and pasting, Qubes requires the additional step of specifying the target domain, so that no other domain can possibly hijack the contents of the clipboard (Figure 5). By default, copying from dom0 is prohibited, except for the copying of logs in a special item in the VM Manager.

Figure 5: Copying in Qubes requires the extra step of defining the target security domain.

Similarly, updating software is generally done from with a security domain other than dom0. If software is installed to dom0 – which should generally be unnecessary – it must go through a process of verification similar to the copying of text snippets or files. In the same way, while Qubes automatically detects external drives, it does not automatically mount them, as most distributions do today. Instead, Qubes requires that users select a security domain for the external drive, select Attach/detach block devices from the menu, and choose the external drive – a process not that different from the former practice 15 years ago of only allowing the root user to mount drives.

Because of Xen's design, conventional burning of external devices is not supported at all. Instead, Qubes' online documentation suggests attaching a SATA optical drive to a secondary SATA controller, then assigning the controller to a VM. Alternatively, users can attach a SATA optical drive to dom0, although this choice violates Qubes' basic security model. However, for those who are security-conscious enough to run Qubes routinely, this limitation is a relatively small price to pay, and the dangers of using dom0 can at least be mitigated by doing check sums on disk images.

Ahead of the Curve

Qubes stands out not only for the elegant simplicity of its security, but for the user friendliness with which its security model is implemented. Once users understand the concept of security domains, using them on the desktop is no more complicated than choosing a document template in a word processor, especially since every action is clearly indicated in a confirmation dialog. Alternatively, for those who want more control over their actions, a handful of commands offers more flexibility.

The main limitation, of course, is that Qubes' hardware requirements are slightly ahead of current standards, let alone what is available on an older system. However, in a couple of years or less, standard hardware should have caught up to Qubes, and the increased interest in security may make Qubes a more plausible option. However, for now, Qubes remains a high-end option, literally ahead of its time.