Labels and Event Processes
in the Asbestos Operating System
Petros Efstathopoulos∗ Maxwell Krohn† Steve VanDeBogart∗
Cliff Frey† David Ziegler† Eddie Kohler∗ David Mazi eres‡ Frans Kaashoek† Robert Morris†
∗UCLA †MIT ‡Stanford/NYU
http://asbestos.cs.ucla.edu/
ABSTRACT
Asbestos, a new prototype operating system, provides novel la-
beling and isolation mechanisms that help contain the effects
of exploitable software aws. Applications can express a wi de
range of policies with Asbestos’s kernel-enforced label mechanism,
including controls on inter-process communication and system-
wide information ow. A new event process abstraction provi des
lightweight, isolated contexts within a single process, allowing the
same process to act on behalf of multiple users while preventing
it from leaking any single user’s data to any other user. A Web
server that uses Asbestos labels to isolate user data requires about
1.5 memory pages per user, demonstrating that additional security
can come at an acceptable cost.
Categories and Subject Descriptors: D.4.6 [Operating Sys-
tems]: Security and Protection Information ow controls, Access
controls; D.4.1 [Operating Systems]: Process Management; D.4.7
[Operating Systems]: Organization and Design; C.5.5 [Computer
System Implementation]: Servers
General Terms: Security, Design, Performance
Keywords: labels, mandatory access control, information ow,
event processes, secure Web servers
1 INTRODUCTION
Breaches of Web servers and other networked systems routinely
divulge private information on a massive scale [23, 32]. The kinds
of exploitable software aws that enable these breaches wil l persist,
but all is not lost if we design systems that limit the possible impact
of most exploits. A powerful tool to contain exploits is the principle
of least privilege [37], which directs that each system component
should have the minimum privilege required to accomplish its task.
A corresponding policy would prevent a server acting for one prin-
cipal from accessing data belonging to another principal through
direct or indirect channels. A least privilege policy, enforced by the
operating system at the behest of a small, trusted part of the ap-
plication, would defang classes of exploits from SQL injection to
buffer overruns, making servers much safer in practice.
Unfortunately, current operating systems cannot enforce least
privilege. Even the much weaker goal of isolating services from one
another (without isolating principal state inside each service) re-
quires ddly and error-prone abuse of primitives designed f or other
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for pro t or commercial advantage an d that copies
bear this notice and the full citation on the rst page. To cop y otherwise, to
republish, to post on servers or to redistribute to lists, requires prior speci c
permission and/or a fee.
SOSP’05, October 23 26, 2005, Brighton, United Kingdom.
Copyright 2005 ACM 1-59593-079-5/05/0010 . . . $5.00.
purposes [20]. Most servers instead revert to the most insecure de-
sign, monolithic code running with many privileges. It should come
as no surprise that high-impact breaches continue.
New operating system primitives are needed [21], and the best
place to explore candidates is the unconstrained context of a new
OS. Hence the Asbestos operating system, which can enforce strict
application-de ned security policies even on ef cient, un privileged
servers.
Asbestos’s contributions are twofold. First, all access control
checks use Asbestos labels, a primitive that combines advantages
of discretionary and nondiscretionary access control. Labels deter-
mine which services a process can invoke and with which other
processes it can interact. Like traditional discretionary capabilities,
they can be used to enumerate positive rights, such as the right to
send to the network. Unlike traditional capability systems, how-
ever, Asbestos labels can also track and limit the ow of info rma-
tion within system- and application-de ned compartments. These
complementary security models are linked by a key observation:
the ability to declassify data in a single compartment is analogous
to possession of a discretionary capability. The resulting system
supports capability-like and traditional MLS [9] policies, as well as
application-speci c isolation policies with decentralized declassi-
cation , through a single uni ed mechanism.
Second, Asbestos’s event process abstraction lets server applica-
tions ef ciently support and isolate many concurrent users . In con-
ventional label systems, server processes would quickly become
contaminated by data belonging to multiple users and lose the abil-
ity to respond to anyone. One x is a forked server model, in wh ich
each active user has a forked copy of the server process; unfortu-
nately, this resource-heavy architecture burdens the OS with many
thousands of processes that need memory allocated and CPU time
scheduled. Event processes allow a single process to keep private
state for multiple users, but isolate that state so that an exploit af-
fects only one user’s data. A group of event processes is almost as
ef cient as a single ordinary process. The event process dis cipline
encourages ef cient server construction, and in our experi ments,
servers can cache thousands of user sessions with low storage costs.
Measurements on an x86 PC show that an Asbestos Web server
can support comprehensive user isolation at a cost of about 1.5
memory pages per user. Furthermore, although our prototype la-
bel implementation impacts performance, an Asbestos Web server
storing isolated data for thousands of users is in some ways com-
petitive with Apache on Unix. Asbestos shows that an OS can sup-
port exible, yet stringent, security policies, including information
ow control, even within the challenging environment of a hi gh-
performance Web server.
2 APPLICATION GOAL
We evaluated Asbestos by implementing a secure application that
we could not build on current systems, namely a dynamic-content
Web server that isolates user data. Our goal, in a nutshell:
1

Asbestos should support ef cient, unprivileged, and
large-scale server applications whose application-
de ned users are isolated from one another by the oper-
ating system, according to application policy.
The rest of this section expands and clari es this goal. Alth ough the
goal refers to server applications, Asbestos mechanisms should aid
in the construction of other types of software. For example, email
readers could use related policies to restrict the privileges of attach-
ments, reducing the damage in icted by users who unwittingl y run
disguised malicious code.
A large-scale server application responds to network requests
from a dynamically changing population of thousands or even hun-
dreds of thousands of users. A single piece of hardware may run
multiple separate or cooperating applications. Examples include
Web commerce and bulletin-board systems, as well as many pre-
Web client/server systems. Such applications achieve good perfor-
mance through aggressive caching, which minimizes stable storage
delays. By ef cient , then, we mean that an Asbestos server should
cache user data with low overhead. This would be simple if the
cache were trusted, but we additionally want to isolate different
users’ data from one another, so that any security breaches are con-
tained. The Asbestos event process mechanism aims to satisfy this
requirement.
By unprivileged, we mean that the system administrator has
granted the application the minimum privilege required to complete
its job, and this minimum privilege is much less than all privilege.
Thus, the system follows the principle of least privilege.
Users are application-de ned , meaning each application can de-
ne its own notion of principal and its own set of principals. One
application’s users can be distinct from another’s, or the user pop-
ulations can overlap. An application’s users may or may not corre-
spond to human beings and typically won’t correspond to the set of
human beings allowed to log in to the system’s console.
By isolated, we mean that a process acting for one user cannot
gain inappropriate access to other users’ data. Appropriate access
is de ned by an application policy: the application de nes which of
its parts should be isolated, and how. The policy should also support
exible sharing among users for data that need not be isolated. All
users must trust some parts of the application, such as the part that
assigns users to client connections; since bugs in this trusted code
can allow arbitrary inter-user exploits, we aim to minimize its size.
The application de nes the isolation policy, but the operating
system enforces it. The OS should prevent even totally compro-
mised processes from violating the policy; for example, they should
be unable to launder data through non-compromised services and
applications. Thus, isolation policies can restrict information ow
among processes that may be ignorant of the policies. Unfortu-
nately, any system that controls information ow through ru n-time
checks can inappropriately divulge information when those checks
fail [31]; in effect, kernel data structures for tracking information
ow provide a covert storage channel. We aim to eliminate sto rage
channels that can be exploited without multiple processes, so that a
later, hardened version of Asbestos can improve security by limit-
ing process creation rates. Section 8 discusses this issue in depth.
In summary, Asbestos must support a form of mandatory access
control, which transitively isolates processes by tracking and limit-
ing the ow of information. Unprivileged applications de n e their
own isolation policies and decide what information need not be
isolated. Furthermore, OS mechanisms for labeling processes must
support highly concurrent server applications.
These Asbestos ideas achieve full expression in the design and
implementation of the Asbestos OK Web server, a much improved
Network Stack (netd)
ok-demux idd
Worker 1 Worker 2
ok-dbproxy Database
Declassifier
Worker
Application
System
Figure 1: Processes of the Asbestos OK Web server. Grey boxes are
trusted. Worker processes contain one event process per user session.
version of the original OKWS for Unix [20]. The server imple-
ments a Web site with multiple dynamic workers one each for
logging in, retrieving data, and changing a password, for exam-
ple. Each worker is its own process; the ok-demux process ana-
lyzes incoming connection requests and forwards them to the rel-
evant worker. Each worker caches relevant user data; caches for
different users are isolated from one another using labels and event
processes. A production system would additionally have a cache
shared by all workers, and Asbestos could without much trouble
support a shared cache that isolated users. We also implemented
SQL database access (table rows are labeled as belonging to partic-
ular users) and declassi ers (selected workers that can exp ort user
data to the public). The workers are untrusted, meaning that worker
compromise cannot violate the user isolation policy. Trusted com-
ponents include the ok-demux process, the ok-dbproxy database in-
terface, and an idd process that checks user passwords, as well as
system components such as the network interface, IP stack, le sys-
tem, and kernel. Declassi er workers are semi-trusted: a co mpro-
mised declassi er can inappropriately leak the compromise d user’s
data but cannot gain access to uncompromised users’ data. Figure 1
shows this server’s process architecture.
3 RELATED WORK
Mandatory access control (MAC) systems provide end-to-end en-
forcement of security policies by transitively following causal links
between processes. Operating systems have long expressed and en-
forced these policies using labels [9]. Labels assign each subject
and object a security level, which traditionally consists of a hier-
archical sensitivity classi cation (such as unclassi ed , secret, top-
secret) and a set of categories (nuclear, crypto, and so forth). To
observe an object, a subject’s security level must dominate the ob-
ject’s. For example, a le with secret, nuclear data should o nly be
readable by processes whose clearance is at least secret and whose
category set includes nuclear. Security enhancement packages sup-
porting labels are available today for many popular operating sys-
tems including Linux [25] and FreeBSD [44].
MAC systems generally aspire to achieve some variant of the
∗-property [3]: whenever a process P can observe object O1 and
modify object O2, O2’s security level must dominate O1’s. In the
absence of the ∗-property, P could leak O1’s contents by writing
it to O2, leaving O1’s con dentiality at P’s discretion rather than
mandatorily enforcing it. Of course, real operating systems do pro-
vide some way to declassify or downgrade data for example ,
as a special privilege afforded certain users if they press the secure
attention key [17] but this lies outside the main security m odel.
Most MAC systems are geared towards military settings, which
require labels to specify at least 16 hierarchical sensitivity classi-
cations and 64 categories [9]. This label format determine s what
2