Kernel Hypervisors

Hypervisors for Security and Robustness

Overview

This web page is a repository for information regarding the Hypervisors for Security and Robustness program, also known as the Kernel Hypervisors program.

The project explores a concept similar to that of a `hypervisor', see the work of Bressoud and Schneider, but implements the hypervisor on top of an operating system kernel rather than on top of the hardware. These kernel hypervisors are constructed from wrappers placed around system calls for selected system components. They could be used to make a component more robust, as described by Bressoud and Schneider, or to perform various security functions such as fine-grained access control and auditing of events.

On this program hypervisors were placed between the kernel and applications, rather than directly on the hardware, to allow for security functions to be defined at the level of abstraction of the applications. This placement also allows several kernel hypervisors, built for different applications, to reside on the same hardware platform. A hypervisor that provides the proper filtering can be used as a firewall around an application. The hypervisor would block inappropriate requests from the application to services such as the file system.

Kernel hypervisors are distinguished by the fact that they consist of loadable kernel code that is used to wrap specific applications. Other approaches have been used to provide wrappers for additional security or robustness including:

Traditional hypervisors that replace the standard hardware interface with an interface that provides additional capabilities. This approach was used by Bressoud and Schneider for building a replication hypervisor that intercepts, buffers, and distributes signals from outside the system.

Special libraries that include security functionality and that are linked with an application before it is run. This is the approach taken by SOCKS where the client links in the SOCKS client library. SOCKS is intended for use with client/server TCP/IP applications, but the concept of linking in special libraries can be used for any type of application.

Wrappers that make use of an operating system's debug functionality. This is the approach taken by the Berkeley group.

Our approach is most like the last, but it differs in that we place our code directly in the kernel and do not use the system debug functionality.

Loadable kernel hypervisors have a number of benefits.

They are unbypassable. Since the wrapper is implemented within the operating system kernel, malicious code cannot avoid the wrapper by making direct calls to the operating system as could be done with code library wrappers. Any such calls will be intercepted and monitored.

They do not require kernel modifications. All kernel hypervisor code is implemented as modules that are loadable within the kernel while the system is running. There are no changes to kernel source code as is necessary with specialized secure operating systems.

They are flexible. Kernel hypervisors can be used both to implement a variety of different types of security policies and to provide replication functionality. Some of the possible applications are discussed below. A key feature is that kernel hypervisors can be "stacked", so that modular security policies can be developed and implemented as needed. We also investigated the implications of this stacking approach using composability theory.

They are not platform specific. Kernel hypervisors can be used on any operating system that supports kernel loadable modules that have access to the system call data structure. This includes Linux, Solaris, and other modern Unix systems, as well as Windows NT.

They can be used to wrap COTS software without any modification to the software (including, e.g., relinking). Kernel hypervisors can monitor the actions of the COTS software and react in a manner that is transparent to the COTS application, other than it may be denied access to certain system resources according to the policy being enforced by the kernel hypervisor.

The objective of this project is to support the DARPA mission to develop technology for information systems that are secure and survivable. In particular, this project supports the construction of such systems using COTS components that are neither secure nor robust, thus allowing systems for advanced defense applications to be built more quickly and at less expense. The goal of this work is to establish a methodology for selectively hardening components for security and robustness and to prototype this methodology on a widely available system. Specific objectives are:

to develop a framework for implementing kernel hypervisors that is easy to administer and that supports unbypassability of the kernel hypervisors
to design and implement a kernel hypervisor that provides additional security protection for the application that it wraps
to design and implement a kernel hypervisor that provides additional robustness for the application that it wraps
to measure the performance impact of these hypervisors
to develop tools that help implement and manage kernel hypervisors
to use composability theory, similar to that defined by Abadi and Lamport and further developed by Secure Computing, to reason about properties of wrapped components from those of the unwrapped components, the kernel hypervisor, and the kernel.

Background

A hypervisor is a layer of software, normally operating directly on a hardware platform, that implements the same instruction set as that hardware. They have traditionally been used to implement virtual machines. Bressoud and Schneider built a hypervisor that intercepts, buffers, and distributes signals from outside the system. Thus, if a service is replicated on several nodes of a distributed system, a signal received by one node will be delivered to all of the replicas, and multiple signals will be delivered in the same sequence on each node. Since the client of the service should only get one copy of a reply, the outputs from all but one of the replicas are discarded. The hypervisor is also capable of detecting failed nodes.

For this project, the hypervisors are being designed to run on the abstract machine consisting of the hardware and the operating system kernel, rather than directly on the hardware. The result is that: the kernel hypervisors will be able to interact directly with applications that are reused on many different hardware platforms, the level of abstraction for component interactions will be high enough to permit important security functions to be provided, and multiple kernel hypervisors will be able to coexist on the same hardware platform. Kernel hypervisors can also be applied to traditional operating system services, such as a file server or a network server, rather than just to applications.

A key concern is that kernel hypervisors may have a detrimental impact on system performance. By adding code to system calls, hypervisors will increase the time for these calls to execute. Fortunately, no additional context switches are involved, since a kernel hypervisor runs in the context of the components for which it is providing a service. Program results include a measure of the performance impact of the hypervisors that we prototyped.

Prototype kernel hypervisors were developed in two areas: security and robustness. For security, the level of control provided by a kernel hypervisor can be used to supplement the control provided by the application and the operating system kernel. Issues investigated included the types of policies that a kernel hypervisor can enforce, the manner by which these policies are defined, and the effectiveness of the kernel hypervisor in addressing the threat at which the policy is directed. A wide range of policies were studied: from auditing, to control of active content downloaded from the Web, to protecting server data from unauthorized modifications, to Type Enforcement, to MultiLevel Security. For robustness, a kernel hypervisor was used to replicate server requests to a backup server, forming a Primary-Backup fault-tolerant service. This type of service is capable of handling fail-stop faults in which a component stops interacting with its environment when it fails.

A specification for a hardened component is the composition of the specification of the original component and the specification of the wrappers making up the kernel hypervisor. Abadi and Lamport have proposed a methodology for specifying components that includes a theorem for determining the properties of the composition from the properties of the parts. For this project, composability theory was used to specify and prove key properties of the composition of the kernel, kernel hypervisors and system components.

Current Status

The focus of the Kernel Hypervisors program is to adapt the concept of a hypervisor for use at the level of an operating system kernel to selectively harden COTS components to provide robustness and security. Using the concept of a loadable module, Secure Computing has implemented kernel hypervisors on a Linux kernel. These kernel hypervisors provide an approach for providing unbypassable security wrappers for application specific security requirements. Kernel hypervisors have a number of potential applications, including protecting user systems from malicious active content downloaded via a Web browser and wrapping servers and firewall services for limiting possible compromises.

On the project, a framework was developed based on a master kernel hypervisor, whose job is to coordinate installation and removal of individual hypervisors. The framework allows kernel hypervisors to be stacked so that a variety of application specific policies can be implemented, each by means of its own kernel hypervisor. The hypervisors run in the kernel, but since they are loadable modules, they do not require the kernel to be modified or even rebooted when they are loaded.

To illustrate the practicality of the kernel hypervisor concept, we prototyped three client kernel hypervisors:

one for wrapping the Netscape browser,
one for replicating files, and
one for wrapping the Apache Web Server.

The goal of the Netscape hypervisor is to protect a user, browsing on the Internet, from downloading and executing malicious active content that might damage the user's system. The Netscape hypervisor accomplishes this by monitoring system calls made by the browser and enforcing a policy that only allows certain resources to be accessed. In particular, the set of files that the browser can open for read, and read/write access is controlled so that the browser effectively operates within its own limited execution context. While this does not prevent malicious code from accessing and possibly damaging resources within this context, it does limit the damage that could be done to only these resources. In the case of the Netscape browser, the context includes the user's .netscape directory as well as limited access to other libraries needed by the browser to execute. Most files on the system, however, are not accessible to the browser and so cannot be damaged. To ensure that applications started from the browser as the result of a download, e.g. a postscript viewer, are also controlled, the hypervisor keeps track of all descendants of the browser and enforces the same policy on them as on the browser.

Based on our experience with the Netscape kernel hypervisor, a generic security hypervisor has been developed that can be used to isolate any application in a compartment from which its access to files can be completely controlled. This generic security hypervisor, plus additional restrictions using techniques developed for the replication hypervisor, were used to develop a security hypervisor for the Apache Web Server. The web server requires two types of protection. First, the server must be restricted to a subset of the file system so that any attack coming through the server will be contained. The second piece of server protection is to isolate the configuration and html files used by the server from modification by un-authorized individuals.

The replication hypervisor is used to transparently replicate a file or set of files. The objective is to provide a replication facility that allows immediate backup of changes to a file without having to modify any applications that are making the actual changes. The replication hypervisor monitors all system calls that modify files looking for calls that modify the set of files to be replicated. When such a call is identified, the hypervisor caches the input parameters and allows the call to continue execution. If execution of the call completes successfully, then the hypervisor sends the cached input parameters to a replication daemon, operating in user space, that replays the call with the cached parameters on the copy of the file that it is maintaining. Via this method, files can be replicated locally or across the network (using NFS).

A composability analysis was performed on the hypervisor framework and the various hypervisors. Four separate, but related, systems were specified. The four specifications are related via refinement. The second and third specifications are refinements of the first; the fourth is a refinement of the second. The systems are:

no hypervisor loaded into the kernel; that is, just one component: the kernel. Since this system has just a single component, composability has nothing to add to the analysis of it. However, the kernel without any hypervisors loaded into it forms the baseline system from which all of the other systems are built.
a two component system consisting of the kernel and a single security hypervisor that monitors write requests loaded into the kernel
an enhanced two component system consisting of the kernel and a single security hypervisor that monitors write requests and return parameters
a multiple component system consisting of the kernel, a master hypervisor and a set of security hypervisors that monitor write requests. In this specification, the single kernel hypervisor has been refined into a master hypervisor and a set of hypervisors each of which have a security policy defined. It is possible to implement a single hypervisor that would behave identically to a system composed of the components specified in this case, but the added complexity of specifying the security policy would make the task very complex.

Each specification describes the individual components of the system and the common state for the composite system. A list of properties satisfied by each component was derived, and composability theory was used to show that these properties are satisfied by the composite system.

More detailed descriptions of the design, testing and composability analysis work is contained in the program documents.

Documents

Conference papers

Using Kernel Hypervisors to Secure Applications

PostScript

Adobe pdf

This paper provides a good overview of the approach and the various components of the system.

Program Documents

Design Report (pdf)

The design report explains the details of the system and internal interfaces.

Test Report (pdf)

The test report documents results of the performance testing performed on the Netscape and Replication hypervisors.

Formal Specifications (pdf)

The formal specifications report documents the results of the composability analysis done on the system.

Final Report (pdf)

The final report summarizes the major accomplishments of the program.

User Guide (pdf)

The User Guide contains installation and use information. The guide should be consulted before attempting to install the kernel hypervisor software.

Code

The kernel hypervisor code developed on the project is available for download. The code is being released for research purposes only and contains no warranties. The download contains both source code, binaries and program documentation in a tarred and compressed file. Please download and read the installation instructions in the User Guide (above) before installing.

Final Code Release

Links

Cornell Hypervisor Project

Hypervisor-Based Fault-Tolerance

PostScript

Adobe PDF

Fred Schneider

This paper describes the author's work in developing a hypervisor that can be used to replicate requests to a server. This is a traditional hypervisor, that is built on the hardware and lies underneath the operating system, as opposed to the kernel hypervisors we are studying on the program, that are built on the OS kernel.

Composability

Conjoining Specifications

Martin Abadi

Leslie Lamport

A Framework for Composability (in PostScript or Adobe PDF formats) by Todd Fine. Presented at COMPASS 96. This paper describes a composability framework that is an early version of the framework used in this program. The framework is based on Lamport's TLA specification language.

Composability project. SCC's DARPA-funded project for composability research. The composability framework used on the Kernel Hypervisors project was developed on this project.

This page is maintained by the Kernel Hypervisors program team

[Home] [Products] [Services] [News] [Reseller Support] [Investor Relations] [Contact Us] [About Secure]

Last update: June 24, 1999.