Exploring the Qubes OS secure operating system
Most operating systems claim to be secure; however, most fail terribly. Newcomer Qubes OS tries a different approach, relying on a microkernel and pervasive virtualization.
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.
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.
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
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.
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.
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 .
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.
Buy this article as PDF
New release marks the arrival of AMD’s unified driver strategy.
A new study by IDC charts big changes in the big hardware market.
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?