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 [1] to these measures, OpenBSD incorporates a number of additional obstacles [2], 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 [3], which is a rootkit that attacks the guest system from within the hypervisor.

Rutkowska is currently working on Qubes OS [4], 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. 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 1: The xinput command-line tool showing input devices.

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). Because the host system does not have network access, only a few components need updates, which the admin installs at the command line [5].

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.

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 [6] 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.