Does the world really need another operating system that claims to be totally secure? It already has OpenBSD, which has reported two remote vulnerabilities in the past 16 years – others can only dream of that kind of security.

OpenBSD also does everything right in terms of its design: It guarantees security through high-quality management, including code reviews, coding standards, and automated tests. According to most experts, checking the code is essential for any secure system, because the majority of all serious security issues are attributable to well-known programming errors.

Break-ins occur because of buffer overflows, format string vulnerabilities, off-by-one errors, and sometimes also because of incorrectly initialized random number generators.

In addition to these measures, OpenBSD incorporates a number of additional obstacles, which greatly complicate attacks if a security-related bug should happen to crop up.

Even Microsoft has copied this part of the strategy for Windows. As a basic rule, prevention is better than a cure. All of the retrofitted security features, such as address space layout randomization, are reactive, meaning that they do not resolve the underlying programming error.

Even the highly successful approaches that have been taken by OpenBSD still do not go far enough, according to Polish security researcher Joanna Rutkowska. She also considers artificial enhancements, such as SELinux, ineffective. Rutkowska is best known for her work on Blue Pill, which is a rootkit that attacks the guest system from within the hypervisor.

Rutkowska is currently working on Qubes OS, which is available under GPLv2; a final Version 2.0 Release 2 (or R2) will probably appear in early or mid 2014.

The current version of Qubes is the Beta 2 from February 2013; a third beta release is still under construction and was actually due for release three months ago.

GUI-Level Separation

One of Rutkowska’s main criticisms of existing security solutions is the lack of security in X11: Because of the biblical age of the X window system, applications are not sufficiently isolated from one other. As a simple demonstration, she proposed a small test with the standard xinput tool and two terminal windows. After entering xinput with no parameters, you see a list of the available input devices. I followed this suggestion in our lab, as you can see in Figure 1, entering

xinput test 8

where 8 stands for the keyboard I am using.

Figure 1: The xinput command-line tool showing input devices.

From this time on, all keystrokes appear as scan codes (Figure 2), even if the person typing uses the second terminal – or is working with root privileges.

Figure 2: The xinput test 8 command records keyboard scan codes – in this case, su - followed by the root password.

In the example, I initially entered su -, which produced the first eight scancodes. I then followed with Enter and the root for Kali VM – if you check this yourself, you will realize that X11 is quite insecure. On the brighter side, this sniffing attack does not work for X11 forwarding via SSH – so attackers at least cannot sniff the commands entered by a person working on a remote computer.

Local input for the remote system can be recorded. Technically, it might be possible to prevent access to the other user’s sphere of activity after entering by su -, but this would only be a stopgap, because no application should receive data from any other.

App Separation

Instead of running all applications side by side, Qubes OS sets appropriate security levels for application groups. These groups run on separate Xen VMs, which isolates the apps far more effectively than a normal operating system would. This encapsulation goes further than in a chroot environment, in which the systems share hardware resources such as network cards.

You might argue that this kind of security measure does not necessitate creating a new operating system distribution. Virtualization tools such as Parallels, VirtualBox, or VMware are capable of providing a similar level of isolation; however, a VM solution is only as secure as the host operating system.

Qubes OS opts for a minimal host, which provides only the GUI: optionally, KDE or Xfce. Everything else, and that includes hardware such as the network card or disk, are separate VMs (Figure 3).

Figure 3: The architecture of Qubes OS: Depending on their security requirements, applications are assigned to app VMs; Qubes abstracts hardware with its own VMs.

Because the host system does not have network access, only a few components need updates, which the admin installs at the command line.

Network Trickery

Outsourcing the network connection offers another advantage: If you need to tunnel to your office through a VPN, you can create a network VM that establishes the VPN connection and then use the network adapter it provides with other VMs. In other words, multiple security environments can share a VPN tunnel that is completely transparent to the individual VM, which also sees nothing of its own network.

In her blog, Rutkowska proposes installing a Tor proxy on a network adapter VM. The application VM does not notice that the network card is doing more than usual – in particular, it cannot work around the Tor proxy. As a consequence: all network traffic is anonymized. This approach prevents the usual attacks on anonymization by, say, Flash plugins.

Small Is Beautiful

Besides good hardware abstraction and encapsulation, another positive feature of Qubes OS is the microkernel architecture: Programs classified as secure should have fewer than 0.5 bugs per 1000 lines of code; the average for typical programs is three to five bugs. Not all bugs are related to safety; many are just plain annoying. However, most of the currently exploited vulnerabilities are caused by typical programming errors.

As the total number of errors decreases, so does the number of security-related bugs. Because a microkernel has fewer lines of code, it has fewer errors, and thus fewer vulnerabilities. Vulnerabilities in the kernel are especially dangerous, so avoiding kernel vulnerabilities is especially critical.

Platform Independent

Thanks to templates for the app VMs, Qubes OS is quite easy to configure; a new VM is quickly set up. The default template in Qubes R2 Beta 2 is based on Fedora 18 (64-bit); initially, the user can choose from three color-coded app VMs – work, personal, and random. The many tips on the website also help users get started.

Qubes OS users are not restricted to one operating system because of the underlying Xen hypervisor and the virtualization technology. Different systems can run on different app VMs.

The wiki for exchanging information with colleagues on the intranet could be based on OpenBSD, for example, for security reasons. MS Office files mailed to you no longer need a viewer: You can read them natively in a Windows app VM. This design creates a high degree of flexibility and security.

Substantial Test Overhead

If you want to quickly try out Qubes OS R2, you’ll have to navigate one major obstacle: The hardware compatibility list is very short. No virtualization environment (Parallels, VirtualBox, VMware Fusion) on the test system I initially used under OS X 10.7.5 was willing to cooperate with Qubes.

The problems with virtualization are underlined by a charming note on the Qubes website, asking users to refrain from posting further requests to the developer team relating to running Qubes in a virtual environment – because it simply does not work. Individual reports on various websites of purportedly succeeding in running Qubes OS in a nested virtualization environment tend to contradict this dire warning, but unfortunately, clear information on the conditions is missing in all cases.

Ultimately, I turned to an old laptop for the test; Qubes was downloaded and burned on a DVD in the old-fashioned way. After a nearly a three-hour-long installation, the test team at least managed to add a new device to the compatibility list: a Macbook Pro from 2007.

Conclusions

Although the concept behind Qubes OS is not revolutionary – app separation processes have been around for some time – the everyday usability of the system and its excellent flexibility, in combination with the considered device abstraction design, make Qubes OS quite unique.

That said, however, the system is still not suitable for everyone, and it provides limited hardware compatibility. Also – as is to be expected of a beta version – some bugs need to be fixed. But, if none of these caveats faze you, you can look forward to a well-designed and, above all, secure system.

The Author

Tobias Eggendorfer is a professor for IT security in Ravensburg, and he also works as a freelance IT consultant. He finds the concept behind Qubes OS interesting enough to investigate it with his students in an upcoming term, while he also looks for creative ways to undermine it.