Security and virtualization often do not come hand-in-hand; merely running a virtualized environment does not automatically provide a guarantee of increased security over dedicated hardware.
As we discuss below, even the basic isolation properties of a VM framework are questionable. Relying on a piece of software to enforce isolation on the x86 platform is risky; it is entirely unclear whether a VMM is going to get that sort of job (a job that OS designers have been grappling with for years) right, especially in the absence of hardware primitives that would make things a lot easier (this argument is the essence of our recent VMSec paper).
This KernelTrap thread captures a vigorous discussion of this exact point.
The use of virtualization to support isolation is really only half a solution. If you take a “deny by default” approach, then you are probably at least as interested in what safe interactions the virtualization framework enables. As Bellovin pointed out in his October 2006 CACM article “Virtual Machines, Virtual Security,” virtual containers need to transfer and exchange information, and what current virtualization platforms seem to lack is a systematic way to talk about the flow of information across the isolation boundaries between virtual containers. He further pointed out that, even if this capability existed, policy writing is still a hard problem that isn’t very amenable to automation.
Note that the general form of this problem (controlling information flow between task units) exists both within the context of traditional operating systems (process, filesystem, and memory space isolation) and in a virtualization environment. Even if a policy framework for controlling information flows between virtual containers (e.g., guest OSs) existed, then all the hard work falls on whoever undertakes the task of policy engineering: specifying the many ways that two or more threads of execution in a fluid set of guests might affect some amorphous set of resources across those guests. The details matter here: the type of events a virtualization system observes has an impact on the performance of the system designed to measure them and make security-related decisions about them.
Applications of Security+Virtualization
Although virtualization can be much maligned, one compelling “security” benefit is business continuity: recovering from a disaster may be quicker and require less fiddling with hardware if your infrastructure is based on VMs. But as with other security-related “features” of a VM framework, the actual utility often depends on how well the framework is utilized by the adopters.
Virtualization serves as an enabler for security solutions — it doesn’t necessarily function as a security provider without some careful thought about the design and management of the systems, processes, and people surrounding it.
There are a variety of creative uses that blend security with virtualization or VM frameworks (VM guests, hosts, hypervisors, VMMs, etc.). Projects involving aspects of virtual machines and security range from those that show how a VM or VM framework can provide or enhance security functionality intrinsically to those that use VMs as containers to form part of a larger security system.
The former type of project looks at what functionality can be added to the VM framework’s code to implement things like access control, trusted computing (TPM support), isolation, malware reverse engineering, virus scanning, network content filters, information flow analysis, and host or network anomaly detection.
The latter type of project employs to VMs to provide a convenient disposable container to examine the execution of a guest application or OS. Some examples of this use include opening potentially infected emails or web pages, testing out patches or other software fixes, and recording application state for replay.
Resource Provider or Reference Monitor?
From a certain point of view, the amalgam of virtualization technology and information security techniques represents a rather strange blend. What does emulation or multiplexing of physical devices have to do with the enforcement of a wide variety of security properties?
The easiest answer (and the most traditional one) is that virtualization provides an effective means of isolating execution environments; virtualization seems like a natural way to provide isolation between execution containers. However, customizing the communication between such containers — in many situations, they do need to communicate: complete isolation is the exception rather than the rule — presents a challenge. Thus, even the “obvious” security application of virtualization is fraught with difficulty.
As organizations increase their adoption of virtualization environments, and with the current industry focus on information security, it is natural to wonder just how a virtualization framework might pull double duty by improving a security posture as well as easing management burden and infrastructure costs.
Besides isolation, virtualization frameworks seem to provide a natural place to implement a reference monitor: a formal, well-defined security construct. A reference monitor provides a low-complexity, trusted (and trustworthy) environment from which to observe the execution of another system and measure a certain set of security-related properties.
Unfortunately, it appears that little thought has been given to what the best way is to combine the twin roles of resource provider and reference monitor within a single virtualization framework. As a result, virtualization environments can find themselves attempting to measure security-relevant properties of a system in
ways that are both creative and convoluted. In essence, the set of events that are interesting from a security viewpoint (and this depends on what type of “security” you’re interested in measuring…from integrity of control flow or data items to information flow to authorization and access control) are not necessarily the set of events that the virtualization framework was built to intercept and observe with a minimal performance impact.
Karger and Safford‘s article in the upcoming issue of IEEE S&P magazine details the I/O complexities of most of the popular approaches to providing virtualization. I and my colleagues Bratus, Ramaswamy, and Smith have a paper at the upcoming VMSec workshop (held with ACM CCS 2008) identifying the problem of designing an efficient event trapping system of use for both security policy enforcement and virtualization.
While the suggestion that the design of current virtualization solutions is actually a hindrance to providing security solutions may not sit well with folks interested in touting a particular virtualization solution’s security capabilities, I would argue that we have a unique opportunity to make sure that VM platforms are designed to do the things we’re asking them to do. Now is also a good time to note that the stunning complexity of VMM I/O subsystems, the performance hacks therein, and the backdoor management interface all suggest that even the basic isolation story rests on somewhat shaky ground.
We find ourselves at a unique point in time: we can try to identify the right design for doing these two disparate tasks at once, or we can muddle through by abusing a framework meant for resource multiplexing rather than program supervision. In either case, we still must balance the tradeoff between the virtualization framework’s I/O architecture and subsystems and the trustworthiness of the reference monitor. Ironically, as we depend on VM frameworks to implement more security functionality, these systems become less trustworthy even as they become more trusted.
This essay first appeared in various forms as my blog posts and comments on GoVirtual.org
