Problem Statement

Today's computer systems have an undeniably bad track record in security. We routinely hear of Web servers and other systems experiencing catastrophic breaches that divulge tens or hundreds of thousands of people's private information. End users suffer from viruses and spyware that, through various applications, infiltrate their operating systems, leak clickstream data, send spam, participate in denial of service attacks, and perform other malicious actions.

Most of these problems can be attributed to two factors: exploitable flaws in software, and users' willingness to run malicious code disguised as legitimate software or documents. Unfortunately, neither factor appears likely to improve significantly in the near future. Thus, the most viable means of improving security in practice may be designing systems that accommodate these threats. For example, an email reader should be able to confine an executable attachment by only giving it access to a display window and perhaps a temporary file system. A Web site should be able to ensure that one user's private data cannot be sent to another user's browser by a buggy Web server.

Confining processes and limiting information flow require the ability to enforce nondiscretionary security policies. To date, most operating system support for nondiscretionary policies has taken the form of multi-level secure (MLS) systems suitable for military-style classification policies. MLS systems primarily allow security administrators to impose external constraints on existing software. The nondiscretionary access control mechanisms in these systems typically cannot be used by ordinary users to craft their own policies, cannot help developers restructure applications to tolerate breaches, and cannot be applied at a fine granularity to protect large numbers of users' data, as would be required for a typical Web site. Language-based information flow systems can support somewhat more decentralized policies [1], but there are significant advantages to implementing flow control at the OS level---not least the smaller trusted computing base and hardware support for protection. Furthermore, even these systems may not support the dynamic, decentralized creation of principals. On the other hand, capability-based operating systems offer some attractive features, including dynamic principal creation and fine-grained access control but give up explicit control of information flow.

Motivated by the difficulty of writing secure code for today's operating systems, and believing that a clean-slate design would more likely lead to advances that could eventually be mapped back to more conventional OSes, we are working on a new operating system, Asbestos, that combines the advantages of capability-based and nondiscretionary-access systems. Asbestos access control is based on a single simple primitive, Asbestos labels, that can implement both discretionary and nondiscretionary access policies, in a completely decentralized fashion. Any process may create an access control space, represented by a handle, and control the policies applied relative to that space. Labels straightforwardly implement traditional capabilities, mandatory access control, and hybrid schemes.

But process-granularity labels themselves are not sufficient to build fast, secure applications. A Web service, for example, may speak concurrently to multiple users. The service author might like to enforce a policy in which no user could see or touch another user's data. Process labels would force such a service to be implemented with one process per user, at significant resource cost. Asbestos therefore supports finer-granularity access control, called label save/restore, that lets a service apply labels selectively to specific memory pages. The operating system ensures, with label checks and virtual memory operations, that pages for a given user are visible only during the processing of requests for that user. Even if one user's instance of the process is broken into, all other user data is safe. This primitive not only helps make applications more secure, it also might facilitate new types of services: users could safely be granted more control over the code running on their behalf, since labels ensure that other users' data will never be compromised.

Progress to Date

To date, we have developed a prototype version of Asbestos, running on real x86 hardware and capable of supporting real applications. A decent portion of our work has focused on the appropriate system call interface and how to expose our security primitives to application developers. The system we arrived at is a message-passing design. Applications communicate with the kernel and with each other via messages sent to communications endpoints, or handles. When applications send messages to handles, and receive messages on the handles they own, they can accumulate labels, which in turn, can restrict the ways in which they communicate. The kernel enforces these labeling operations, and an application usually cannot change its labels in a way that gives it more access to system resources. Application designers then must build software with the kernel's labeling rules in mind. In our experience, the labeling restrictions do not preclude the development of a complex piece of software running on behalf of many principles, such as a dynamic Web server.

Our implementation of Asbestos puts these labeling concepts into practice in a real operating system. Moreover, it applies them to fine-grained containment regions---virtual pages on the x86 architecture. Asbestos uses the standard x86 VMM system to restrict which pages a process can read or write on the basis of which labels it currently possesses. If an application is tainted with restrictive labels, many pages in the application's process space will be off limits. The kernel allows the application to flush these labels, but only after scrubbing any data written to memory that might potentially leak information.

In practice, this design means that one application can securely speak for many external users. When an application accepts a connection from an external principal (X), it is immediately tainted with X's labels. It can write to a pool of memory specifically allocated for X, but cannot read or write Y's pages. After serving X's request, the application flushes its labels and accepts a new connection from Z. At that point, the application can only access Z's memory pages, those from X being pushed out of scope by the label flush operation.

An actual implementation of a Web server that enforces such a policy exists for Asbestos. The Web server makes heavy use of Asbestos's labeling interface, supplemented with small trusted applications (tasked with applying the appropriate labels to incoming connections), so that the Web server could be entirely compromised without leaking data.

Future Work

Research on Asbestos is currently progressing in many different directions. Work is ongoing to make Asbestos perform better, and to support more hardware. In particular, we seek to optimize the virtual memory operations that must happen whenever an application flushes its labels and attempts to speak for a new user. Other work is dedicated to rethinking, and possibly simplifying the current Asbestos labeling scheme. For instance, page labeling can replace the need for memory-protection along process boundaries. Might it be possible to develop a similar operating system without the idea of a process? Other work is devoted to making more Asbestos applications. In keeping with our current emphasis on Web services, we are designing and implementing a database server for Asbestos that can assign different labels to tables, rows and even cells. The idea is that data imported to and exported from the database follow the same labeling rules as other aspects of the system. Finally, we are exploring programming-language techniques to simplify building applications on Asbestos: if a program might eventually induce a run-time label failure, then perhaps the offending operation should be discovered when the program is compiled.

References:

[1] A Decentralized Model for Information Flow Control. In Proceedings of the 16th ACM Symposium on Operating Systems Principles, Saint-Malo, France, October 1997.