Security through isolation

Server virtualisation

Businesses have embraced virtualisation with a vengeance. The key driver, of course, is cost. Cramming several servers on one machine helps you sweat your systems, reduces your carbon footprint and saves you money.

But many organisations have also woken up to the fact that virtualisation also helps you isolate problems. It's perfectly possible to run several server applications - mail, web, filesharing, print sharing and so on - on one physical machine. But with each application safely inside its own Virtual Machine (VM), if a vulnerability in, say, IIS leads to your web server being compromised, the rot can't spread any further. VMs are inherently damage-limiting, to a point.

One problem is that the safety benefits rely on organisations doing the job properly. According to a Gartner report, 60 per cent of virtualised servers will be less secure than the physical servers they replaced.¹ It seems that the prospect of inherent security is making people sloppy.

 

Shy bugs

The native protection offered by VMs makes virtualisation particularly popular among anti-malware researchers. They can run multiple machines on one piece of hardware, each doing its best to be compromised so that the researchers can study viruses, trojans and other nasties. And the malware writers know this. They often configure their malware so that it looks to see if it is being run in a virtual environment: if it is, it switches off, denying the researchers the opportunity to detect and study it.

The corollary of that is that using virtualisation gives you added protection against many species of malware. It doesn't apply to all malicious software, of course, but you might consider any extra degree of defence worth having.

 

Ethos

Researchers haven't been slow to see the potential. Goaded by the increasing menace of botnets, work began in 2007 on a secure operating system, Ethos, built on the Xen hypervisor. The effort is being led by Jon Solworth of the University of Illinois at Chicago, with support from cryptographer Daniel Bertstein and a team of contributors.

The basic concept behind Ethos is to separate major applications by running each in its own VM. The operating system will use a high level of hardware abstraction, says Solworth, and will closely examine the security of each and every system call. So the OS is being built piece by tiny piece with the aim of exposing possible vulnerabilities at every step and securing each part of it. It's a slow process which may be accelerated somewhat by a recent grant of $1.15 million from the National Science Foundation.²

 

Qubes

You don't have to wait until Solworth and his team finish their work, however. Another secure OS is already freely available as an open source offering. Qubes is the work of Joanna Rutkowska, better known for rootkits, and Rafal Wojtcuk, both of Invisible Thing Lab.³

Qubes goes further than other approaches by employing virtualisation at the application, rather than server or client PC, level.⁴ Each application runs in its own VM - dubbed an AppVM. The architecture again uses Xen as the hypervisor and is also designed to exploit hardware-level security technologies such as Intel VT-d and Trusted Execution Technology. The Qubes approach accepts that creating a new OS from scratch is unrealistic (not least, because people want to use their current applications) but that attempting to patch all the holes in current operating systems is futile. The answer is a middle path - to accept that vulnerabilities exist, but to limit the damage through isolation.

 

Domains

In the Qubes model, VMs are known as domains, perhaps to distinguish them from traditional virtualisation approaches. The familiar VM is, in effect, a complete computer, with OS, GUI, drivers and applications. The Qubes domain is a smaller unit, perhaps responsible for a single application, or small group of apps. Each domain is given the fewest possible privileges.

There is also a system administration domain (known as Dom0) providing some essential OS capabilities. This is the only ‘privileged' domain where compromise by an attacker would give complete access to the system. It has almost the same level of privileges as the hypervisor itself. For this reason, it has no connection to the outside world - it is separated, for example, from the networking domain and the degree of interaction between Dom0 and application VMs is kept to a minimum. Dom0 is also home to the GUI subsystem, which we'll meet in a moment, and the XenStore daemon responsible for a system-wide registry which, among other things, manages backend devices. There is little else in Dom0, however, which interfaces with the other VMs and that helps keep the attack surface small.

 

Application domains

In Qubes terminology, the Dom0, networking and storage domains are SystemVMs which provide system-wide services and are common to all installations of Qubes. On top of those, you have user-defined ‘AppVM' domains, and these are configured according to their function and required security level. For example, Rutkowska and Wojtcuk give the following examples:

Random domain: for casual web browsing and non-sensitive applications that use no personal data.

Social domain: for social networking, emailing, blogging - anything that involves the user's social identity, so that any security policies for this domain are geared to protecting that identity.

Other domains suggested by Rutkowska and Wojtcuk including Shopping, Banking and Corporate, each of which deals with different kinds of sensitive data and may require different policies regarding networking, data storage and so on.

All user data resides in the AppVMs. If you run your email client in the Corporate domain, that's where the messages (and their attachments) stay. You can always run a separate email client in your Social domain, for personal use. That way, poor personal habits won't compromise your job.

Each AppVM runs its own OS. During these early days for Qubes, that OS has been Linux, but it's possible that others will follow and Qubes could support a mixture of operating systems.

However, the critical difference between this approach and normal uses of virtualisation is that, with Qubes, you have multiple VMs for a single user, as opposed to completely separate VMs performing as though they were individual machines each with its own user or users. And Qubes' multiple VMs operate through a single GUI.

 

Storage

While an AppVM is running its own OS, it doesn't need to full capabilities of that system. It will use the SystemVM storage domain as a read-only filesystem for much of the system code and Dom0 for the GUI, which reduces duplication. Each AppVM can therefore run on a stripped-down, lightweight version of the OS.

Current versions of Qubes are built on Linux, which benefits already from the *nix systems of permissions that isolates certain parts of the filesystem from ordinary users. In Qubes, this is taken further, with the filesystem being split between SystemVMs and AppVMs.

An AppVM needs access to the root filesystem (eg, /boot, /bin, /user), but in Qubes this is provided by a read-only block device that is shared among all the AppVMs (employing a Copy On Write (COW) device to avoid the problem of Linux implementations baulking at using a read-only device). The user data for individual applications is stored in the relevant AppVMs.

 

 

Networking

Networking is obviously critical when it comes to security. That's why networking capabilities are consigned to their own domain and there is no networking between VMs. Applications that require networking communicate with the network domain via virtual interfaces. And it's possible to configure AppVMs to disallow networking entirely.

 

 

GUI subsystem

The GUI is highly critical from a security perspective, which is why it's located within the same domain as the administrative functions. An attacker gaining control of the GUI system, for example, can do anything a legitimate user can do by mimicking mouse and keyboard input. And so, in addition to sharing the Dom0 domain's isolation from world-facing systems, such as networking, there is also a special interface between the GUI subsystem and the applications.

Each AppVM runs an agent, QubesWM, a kind of window manager that handles the task of rendering that application in the GUI subsystem running in Dom0. For each AppVM, there's a stub application, AppViewer, running in Dom0 that interacts with the QubesWM agents.

The job of the QubesWM agent is to tell AppViewer about new windows on the AppVM's desktop, send notifications about changes to windows, manage focus and relay mouse and keyboard input.

 

 

Qubes allows the creation of policies for exchanging data between VMs. It's also possible to cut and paste between applications in different domains using special key combinations. But access to the clipboard buffer is strictly controlled and some domains may have no access at all.

 

The user problem

Not even Qubes can protect users against themselves. In common with many advanced security concepts, Qubes relies on the system being suitably configured. You have to decide what domains to establish and the privileges that each should have. Some of these - the system-level domains - would be configured out of the box: but others - such as the Social and Random domains in the examples given by Rutkowska and Wojtcuk - require the user (or tech support) to define and implement policies. Such policies might include, for example, only allowing HTTPS over SLL connections from one domain (eg, Banking) while another (such as Random) would be allowed any HTTP traffic.

This could limit Qubes' usefulness to organisations or power users where technical know-how and security awareness are available.

"In Qubes we certainly assume a reasonable user," says Rutkowska. "Our future target users would be lawyers, doctors or some other business people, not necessarily IT experts, who understand the need to protect their data and understand the basic security by isolation paradigm."

That said, even without sophisticated policies for the AppVMs, Qubes' separation of the Dom0 (system and GUI), networking and storage domains would provide considerable extra security out of the box.

 

References

1. ‘Addressing the Most Common Security Risks in Data Center Virtualization Projects', Gartner, January 2010 http://bit.ly/bY5mYd

2. ‘Ethos: an operating system which creates a culture of security', http://rites.uic.edu/~solworth/ethos.html

3. Qubes website: http://www.qubes-os.org

4. ‘Qubes OS Architecture', Rutkowska and Wojtczuk, Version 0.3, January 2010, http://qubes-os.org/files/doc/arch-spec-0.3.pdf