Verifying the EROS Conﬁnement Mechanism£
Jonathan S. Shapiro Sam Weber
IBM T.J. Watson Research Center
Abstract Boebert  and Karger  have argued that unmodi-
ﬁed capability systems cannot enforce even basic manda-
Capability systems can be used to imple- tory access controls such as the *-property. Both have pro-
ment higher-level security policies including the posed solutions in the form of hybrid protection architec-
*-property if a mechanism exists to ensure conﬁne- tures. Karger has also argued that unmodiﬁed capability
ment. The implementation can be efﬁcient if the “weak” systems cannot enforce conﬁnement . Given that EROS
access restriction described in this paper is introduced. is a pure capability system, and that its security design rests
In the course of developing EROS, a pure capability on its ability to enforce conﬁnement, a rigorous veriﬁcation
system, it became clear that verifying the correctness of the of the EROS conﬁnement mechanism is necessary.
conﬁnement mechanism was necessary in establishing the As described by Lampson , the conﬁnement prob-
security of the operating system. lem is to establish a runtime compartment satisfying two
This paper presents a veriﬁcation of the EROS conﬁne- requirements. First, entities inside the compartment may
ment mechanism with respect to a broad class of capability transmit information to entities outside the compartment
architectures (including EROS). We give a formal statement only via authorized channels of communication. Mutations
of the requirements, construct a model of the architecture’s inside the compartment therefore may not be observed out-
security policy and operational semantics, and show that side the compartment unless explicitly authorized by the
architectures covered by this model enforce the conﬁnement client. Second, entities outside the compartment may not in-
requirements if a small number of initial static checks on spect entities inside the compartment without their consent.
the conﬁned subsystem are satisﬁed. The method used gen- We deﬁne a conﬁnement policy that ensures these require-
eralizes to any capability system. ments by testing whether a set of initial static preconditions
Keywords: operating systems, capability systems, proof of
correctness, conﬁnement, veriﬁcation, formal speciﬁcation. 1. All capabilities initially held by the conﬁned subsys-
tem either (a) convey no mutate authority, (b) are au-
thorized channels, or (c) are capabilities to construc-
tor that (recursively) instantiate conﬁned subsystems.
1. Introduction Since no unauthorized mutations are possible, no ex-
ternal observations of unauthorized mutations are pos-
EROS  is a pure capability system that provides a sible.
mechanism for creating and instantiating conﬁned subsys-
tems: the constructor. This mechanism is part of the sys- 2. No entity outside the conﬁnement boundary holds read
tem’s trusted computing base. EROS is a clean-room reim- authority to any entity within the newly instantiated
plementation of the KeyKOS architecture [2, 6] (originally conﬁned subsystem.
called GNOSIS ). It builds on the KeySafe  design
We will show that this policy can be enforced in capability
as the basis for mandatory security policy enforcement. The
systems, and can be enforced efﬁciently if a new primitive
security enforcement provided by KeySafe is predicated on
access right is introduced.
the correctness of the constructor.
This paper does not address the issue of covert channel
£ This work is a continuation of work started at the University of Penn-
suppression. While important, reducing such channels is
sylvania. Portions of this were supported by DARPA under Contracts
#N66001-96-C-852, #MDA972-95-1-0013, and #DABT63-95-C-0073.
largely orthogonal to restricting explicit information ﬂow,
Additional support was provided by the AT&T Foundation, and the and is of interest only when it has ﬁrst been shown that
Hewlett-Packard and Intel Corporations. overt channels have been closed. Similarly, this paper does
0-7695-0665-8/00 $10.00 ã 2000 IEEE
not consider issues such as off line data forensics or mod- via capability-controlled structures. Both address transla-
iﬁcation of the store by a party with physical access to the tion and process state structures are stored in nodes (the
machine. EROS term for c-lists). Data and capabilities are partitioned
KeySafe enforces mandatory security policies across to prevent forgery.
conﬁned compartments. Communication between compart- For purposes of veriﬁcation, the essential EROS re-
ments is mediated by a user-level reference monitor, which source types are processes, data pages, capability pages, and
relies on knowledge of the semantics of the “primitive” ob- nodes.1 A process names an address space and executes the
jects to decide what operations and authority transfers are program in that address space in the usual way. Load and
authorized. To allow later revocation, the reference monitor store operations require that data go to data pages and capa-
inserts transparent forwarding objects in front of all capa- bilities to capability pages and nodes. Address spaces are
bilities that are allowed to pass from one compartment to constructed as a tree of nodes whose leaves are data pages.
another. Implementing the reference monitor outside the A complete process showing all resource types is shown in
kernel allows policies to be updated as new primitive object Figure 1.
types are introduced, and facilitates adaptation of manda-
tory policies to the needs of particular applications. Page
In this paper we show that the conﬁnement test used by 0 15
the EROS constructor mechanism is correct. That is, we Null
model a broad class of capability systems, and show that Capability
given a correct implementation of any capability system sat- Node
isfying our model, the checks performed by the constructor
certify that the newly instantiated service is properly sand- Process node node
0 15 0 15
boxed, and that (unless permitted by the service) the client
cannot inspect the service. To verify that EROS can enforce
conﬁnement, we have developed a formal statement of re-
quirements and a simpliﬁed model, SW, that is both strictly
more powerful and more general than the EROS architec-
ture. SW treats the OS-provided primitive operations as a
serializably concurrent language whose operations are the Pages Page
kernel calls. We have modeled EROS’s security policy, ac-
cess control mechanisms, and operational semantics, and Figure 1. An EROS process
have shown that the EROS semantics satisﬁes the require-
ments of conﬁnement.
The balance of this paper proceeds as follows. Sec- The EROS object and protection model are extended to
tion 2 presents a brief summary of EROS and the construc- secondary storage by transparent persistence . This en-
tor mechanism, and provides an informal intuition for why sures that the security model does not change at the sec-
the constructor mechanism results in conﬁnement. Having ondary storage boundary. Periodically, the system performs
described the architecture and mechanism, we describe and an efﬁcient checkpoint operation, recording the state of
justify key parts of our modeling and proof methodology all objects changed since the last snapshot, including pro-
(Section 3). Section 4 presents the model itself, the formal cesses. There is no kernel-implemented ﬁle system; if ﬁle-
statement of requirements, and the key pieces of the correct- like behavior is required by an application, a process is con-
ness proof (an unabridged proof may be found in [18, 21]). structed that implements ﬁle behavior.
Some related work is discussed in Section 5. Finally, we
discuss the implications of this work and its effect on the 2.1. The Weak Attribute
original system architecture and design.
While a read-only capability prevents modiﬁcations to
2. EROS and the Constructor the resource it designates, it permits the holder to fetch any
read-write capabilities that may reside in that resource. The
EROS  is a pure capability system. The architec- 1 In the interest of brevity, we have omitted from this paper several capa-
ture incorporates what has come to be the conventional non- bilities and attributes whose semantics are a subset of some other object
buffering interprocess communication primitives [12, 19], we have included. We have also omitted explicit consideration of device
drivers (which are presumed to be holes) and certain capabilities such as
with a novel twist providing for “at most one” reply. Meta- “number capabilities” that convey no authority. Details of these can be
data such as mapping structures that are typically consid- found in [17, 18, 21].
ered part of the operating system are exported by EROS
0-7695-0665-8/00 $10.00 ã 2000 IEEE
weak attribute enforces transitively read-only access. If an 3. Veriﬁcation Requirements and Modeling
invocation on a capability, such as the “fetch” operation on Method
a node capability, would return some other capability, and
the invoked capability is weak, then returned capabilities
To verify the constructor mechanism, we must construct
are ﬁrst reduced in authority by marking them read-only
SW, a model of the EROS system, specify the requirements
and weak. The read-only restriction ensures that the imme-
of conﬁnement in terms independent of both the access con-
diate object cannot be modiﬁed. The weak restriction en-
trol model and the operational semantics, and describe the
sures that read-only semantics will be enforced transitively
access control model. Finally, we must show that the sys-
through subsequent capability fetches. The weak attribute
tem’s security policies implement its requirements.
is a generalization of the KeyKOS  sense capability.
System Model Because EROS is persistent, a natural
2.2. Constructors level of analysis is to examine operations on nodes and
pages. The only additional state saved by the EROS check-
The constructor is a trusted EROS application that point mechanism is the list of currently running processes
builds new program (or subsystem) instances and certiﬁes at the time of the checkpoint. All operations performed by
whether these instances are conﬁned. The developer (or the kernel consist of modiﬁcations to nodes and pages.
installer) of an application obtains a constructor that ini- SW may safely deviate from the actual system provided
tially holds no capabilities, and installs those capabilities that SW is at least as powerful as EROS. Any behavior that
that an instance of the application should hold when it is could occur in EROS must be possible in SW. If this is so,
ﬁrst started. As each capability is added to the constructor, and if no information can ﬂow out of a conﬁned subsystem
the constructor examines it to see if it conveys any authority in SW, then the same will hold true in EROS. For modeling
to mutate objects. A capability is “safe” if: purposes, we have made several departures from the actual
¯ It trivially conveys no mutate authority, or system:
¯ It is a read-only, weak capability, or 1. The model uses permissions rather than restrictions.
¯ It is a capability to a constructor that (recursively) gen- This is merely a switch from subtractive to additive
logic. While the model is richer than the system, every
erates conﬁned products.
capability permission existing in the real system can
If the capability is not safe, the constructor records it in a be captured using the permissions of the model.
set of known holes. When all desired capabilities have been
installed, the builder then “freezes” the constructor, after 2. In the model, no distinction is made between nodes,
which it will accept no further capabilities. Once frozen, pages, and processes. Note that processes are strictly
all holes are known to the constructor, and the constructor more powerful than either nodes or pages, and that SW
can therefore determine whether the program instances it is therefore more powerful than EROS as a result of
creates are conﬁned. this simpliﬁcation.
When a client wishes to create a new instance of a sub-
system, such as a ﬁle or a sort utility, it presents a set of au- 3. The real system uses objects of bounded size. The
thorized capabilities to the constructor and asks if the con- model uses sets, both to avoid dependency on any par-
structor output (the “yield”) is conﬁned modulo those capa- ticular object size and to generalize the model to cover
bilities. If ÓÐ × ÙØ ÓÖ Þ , the product is conﬁned. similar systems.
The intuition is this: there is no way to cause damage via
safe capabilities, and the user has authorized all of the oth- 4. EROS keeps capabilities and data in objects of distinct
ers. Because capabilities to safe constructors are safe, the type. SW allows objects to contain both, but the op-
constructor mechanism permits relatively complex subsys- erational semantics has no operations that allow them
tems to be built behind a conﬁnement boundary. to be interconverted. One may imagine the model ob-
Weak capabilities allow a capability pointing to a com- jects to consist of a data part and a capability part. The
plex structure to be added safely without requiring that the EROS system represents the subcase in which either
structure be traversed. Safety might also be accomplished the data or the capability part of each object is required
using a “deep copy” of the structure, but the weak access re- to be empty.
striction makes the copy unnecessary, and thereby allows a
dominating compartment to be granted weak access to con- 5. EROS has process states, three invocation operations,
tent in a lesser compartment without the need for further and a special capability type supporting return-once
mediation. It also allows multiple readers to have consistent semantics. In this paper, we have simpliﬁed this to
read-only access to a data structure that is being updated. a single, more general invocation type and omitted the
0-7695-0665-8/00 $10.00 ã 2000 IEEE
special capability type. Earlier versions of the opera- veriﬁable based on a modest set of initial conditions. This
tional semantics and proof have included both [18, 21]. eliminates the need to dynamically interpret the actions of
Their omission here is for brevity and clarity. the conﬁned subsystem. By looking only at a small portion
of the current system state, the constructor must be able to
6. Reading a page in EROS produces the value that was judge the conﬁnement of its products.
last written. SW does not keep track of the contents of
pages. Ignoring page state results in a more powerful
The function ÑÙØ Ð Ë ´ µ takes a single state Ë and
from that computes the set of all the entities that might in the
model: processes are maximally hostile. Finally, we future be mutated by the entities . Although this function
demonstrate that the security of EROS does not rely is not actually computed by the operating system (for obvi-
upon values computed by applications. ous efﬁciency reasons), it is the basis for the access checks
7. The EROS storage allocator is implemented by trusted performed by the operational semantics. The check per-
user-level software. In SW, its behavior is represented formed by the constructor therefore provides a conservative
by the Ö Ø ´µ and ×ØÖÓÝ ´µ operations. A compli- veriﬁcation of the requirements.
Proof of Correctness To show that the system’s security
cation potentially arises from the fact that the real sys-
tem reallocates objects. When an object is destroyed, policies implement its requirements, we must show that if
the allocator reinitializes the object and invalidates all is an execution of the system whose initial state is Ë¼ , and
capabilities to that object by incrementing its version if is any set of resources, then
number. Since there is a ﬁnite bound on version num-
bers, and each version is allocated at most once, we
ÑÙØ Ø ´ µ ÑÙØ Ð Ë ´ ¼ µ
consider each version of an EROS object to be a dis- In other words, if some entity was mutated in an execution,
tinct SW object for modeling purposes. then the security policy must have said that it was originally
mutable. This statement relies upon properties of both the
8. Real applications obey sequential programs, and their
operational semantics, and the security policy. One of the
behavior is highly predictable. SW instead assumes
aims of this work is to state these properties in such a way
that the behavior of a program is completely nondeter-
as to be applicable to other situations.
ministic. If it is possible for a program to perform a
particular operation, SW assumes that it does so. This
means that the veriﬁcation’s correctness does not rely 4. EROS Veriﬁcation
on peculiarities of instruction sequencing.
SW is a structured operational semantics whose judg-
Each of these changes makes SW more powerful than ments are of the form
Requirements Statement A conﬁned process should Ë¼ Ë½
not be able to affect any non-authorized entities outside
the conﬁnement boundary. Given an execution and a with the intended meaning “When the system was in state
set of conﬁned entities we want to deﬁne a function Ë¼ , action/kernel call « occurred, which resulted in state
ÑÙØ Ø ´ µ whose value is the set of entities in the sys- Ë½ .” There is no strong distinction in SW between processes
tem (conﬁned or otherwise) that were affected by in the and objects; a process is simply an object that initiates an
execution. By doing so, we state what the communication action. The term “process” is used solely as a descriptive
channels of the system are. The ÑÙØ Ø relation is transi- convenience to distinguish actor from actee.
tive. Suppose a process Ô modiﬁes a resource Ü, and another
process Õ subsequently reads Ü. In this sequence of events, Ô 4.1. Semantic Entities of SW
has mutated Õ , even though the two processes never directly
communicated. Our deﬁnition of ÑÙØ Ø takes this form Figure 2 gives the basic semantic entities of SW. The
of indirect communication into account. system resources consist of objects. If is a capability,
Similarly, we deﬁne the function Ö ´ µ to be the set ØÖ Ø ´ µ is the resource that capability refers to, and
of entities in the system (conﬁned or otherwise) that E read Ö Ø× ´ µ is that capability’s access rights. Access rights
(directly or indirectly) in the course of the execution. This are represented as a subset of Ê Û Ö ÛÖ Ü .
deﬁnition includes both entities read directly via an oper- Ö ÛÖ
The , and Ü rights correspond to the conven-
ation such as a load, and also entities whose value is “ob- tional read, write, and execute permissions. The effect of
served” during the course of the computation. Û permission is to ensure transitive read-only access as
Access Control While the conﬁnement problem require- described in Section 2.2. Use of permissions rather than
ments are stated in terms of the execution of the system, restrictions departs from EROS, but we have found that it
it is desirable for the corresponding security policy to be makes the model easier to understand and work with. The
0-7695-0665-8/00 $10.00 ã 2000 IEEE
Universal Sets 4.2. Operational Semantics
Ç Ø the set of objects We deﬁne the transition relation ¡ Ë ¢ Ë as
Ô× set of capabilities follows:
Ê « ¼
set of access rights
Ë set of system states
set ofÇ Ø ¢ ÓÔ Ö Ø ÓÒ× where the state transformation performed by each action «
is given in Figure 4. The data read and write operations
Capability Types do not affect the state at all. Since these operations only
affect pages, and the system state is only kernel data, this
Ç Ô the set of object capabilities is correct. Note that the fact of a read or write operation is
observable – the requirements statement will insist upon the
Utility Functions proper security behavior.
The function Ö ×ØÖ Ø ´ Ö µ returns a copy of the capa-
Ø Ö Ø´¡µ Ô× Ç Ê Ø bility in which all access rights in Ö have been removed
Ö Ø×´¡µ Ô× ¾ fromÖ Ø× ´ µ.
ØÓÖ´¡µ Ç Ø Ö ×ØÖ Ø´ Öµ Ç Ô´Ø Ö Ø´ µ Ö Ø×´ µ Öµ
Figure 2. Semantic entities
The function ´Ñ µ removes all elements of
from the mapping Ñ. It is used in the deﬁnition when all
System state: Ë ´Ë Ü ×Ø Ë Ô× Ë µ ¾Ë outstanding capabilities to an entity must be destroyed.
Ë Ü ×Ø Ç Ø the set of live objects
The transition relation ¡ is well-deﬁned. That is, if Ë
Ë Ô× Ç Ø ¾ Ô× the map between objects Ë ¼ , then Ë ¼ is a state.
and sets of capabilities
Ë Ç Ø the set of all objects which
This lemma is proven by straightforward case analysis.
have been destroyed 4.3. Security Requirements
To state the EROS security requirements we must be
Ë Ü Ë and Ë are disjoint able to determine the set of entities that a given subsys-
2. ¾ Ó¾Ç Ø Ë Ô× ´Óµ µ Ø Ö Ø´ µ ¾ Ë Ü ×Ø tem has mutated during the course of an execution. Sim-
ilarly, we have to deﬁne the entities a subsystem has read
from. As discussed in the requirements statement, we de-
Figure 3. System state
ﬁne a function ÑÙØ Ø
´¡µ with the intended meaning
that if Ë¼ ½ Ë½ ¾ ËÒ is an execution, and
functionØÓÖ ´¡µ associates a unique process with each ac-
Ç Ø ÑÙØ Ø
, then ´ µ is the set of entities
tion. We use as a constructor: if Ó ¾ Ç, Ø that have been affected by the entities in the execution
then Ç Ô Û ´Ó µ is the unique weak capability that
(Figure 6). We use the expected auxiliary deﬁnitions for
ÛÖÓØ ØÓ ´¡µ and Ö ÖÓÑ
´¡µ which for each action indi-
refers to Ó.
cate which resources the executing process could have af-
The deﬁnition of SW state is shown in Figure 3. The fected or been affected by, respectively. The notion of a
sanity conditions ensure that we do not have to deal with subsystem having read the values of other resources can be
nonsensical capabilities. The set of dead objects exists so considered the inverse of mutation: instead of information
that we can ensure that newly created objects are distinct ﬂowing out from the subsystem in question, it is ﬂowing in-
from any that have been destroyed. We treat processes as ward. Therefore, we deﬁne the Ö function in terms of
completely non-deterministic, able to invoke any capabili-
ties that they have in their possession.
ÑÙØ Ø : if Ü mutated Ý , then Ý must have read from Ü.
The set of possible actions in the model are enumerated 4.4. Correctness of Access Control
in Figure 4. We assume that each action is an operation
performed by some process. The restrictions on the actions The EROS system uses capabilities as its primitive pro-
indicate the required access rights to perform the operation. tection mechanism. The access restrictions of these capabil-
0-7695-0665-8/00 $10.00 ã 2000 IEEE
Action Type Restrictions Description
Ö ´Ô µ ¼ Û Ö Ö Ø×´ µ ¼ read data from an object
ÛÖ Ø ´Ô µ ÛÖ ¾ Ö Ø×´ µ write data to an object
Ø ´Ô Û Ö Ô× Ö Ø×´ µ
¼ ½µ ¼ fetch capability from an object
½¾ Ë ´Ø Ö Ø´ µµ ¼
×ØÓÖ ´Ô ½µ ÛÖ ¾ Ö Ø×´ µ ¾ Ë Ô×´Ôµ store capability to object
Ö ÑÓÚ ´Ô ÛÖ ¾ Ö Ô×Ø×´ µ
¼ ¼ ½
¼ ½µ ¼ remove capability from object
½¾ Ë ´Ø Ö Ø´ µµ ¼
ÒÚÓ ´Ô µ Ö
Ü ¾ Ô× Ø×´ µ invoke a process
Ö Ø ´Ô µ
Ë ´Ôµ create new object with capabilities
×ØÖÓÝ´Ô ¼µ ÛÖ ¾ Ö Ø×´ µ ¼ object destruction
In all cases, Ô ¾ Ë Ü ×Ø , ¼ ¾ Ë Ô× ´Ôµ, Ë Ô× ´Ôµ.
Ö ´Ô ¼µ
ÛÖ Ø ´Ô ¼µ
Ø ´Ô ½µ if Ö ¾ Ö Ø×´ µ then
Ë ¼ Ô×´Ôµ Ë Ô× ´Ôµ
else if Û ¾ Ö Ø×´ ¼ µ then
Ë ¼ Ô×´Ôµ Ë Ô× ´Ôµ Ö ×ØÖ Ø´ ½ Û µ
×ØÓÖ ´Ô Ë ¼ Ô× Ë Ô× Ø Ö Ø´ ¼ µ Ë Ô×´Ø Ö Ø´ ¼ µµ
Ö ÑÓÚ ´Ô
¼ ½ µ Ë¼
Ô× Ë Ô× Ø Ö Ø´ µ Ë Ô×´Ø Ö Ø´ µµ ½
¼ ¼ ½
ÒÚÓ ´Ô µ let Ô¼ Ø Ö Ø´ ¼ µ in
Ë ¼ Ô× Ë Ô× Ô¼ Ë Ô×´Ô¼ µ
Ç Ô´Ø Ö Ø´ ¼ µ Ü µ
Ö Ø ´Ô µ let Ó¼ ¾ Ç Ø Ë Ü ×Ø Ë in
Ë ¼ Ü ×Ø Ë Ü ×Ø Ó¼
Ë ¼ Ô× Ë Ô× Ó¼ Ô Ë Ô× ´Ôµ Ç Ô´Ó¼ Êµ
×ØÖÓÝ´Ô ¼ µ let Ç Ô´Ø Ö Ø´ ¼ µ Öµ in
Ë ¼ Ü ×Ø Ë Ü ×Ø Ø Ö Ø´ ¼ µ
Ë¼ Ë Ø Ö Ø´ ¼ µ
Ë ¼ Ô× Ö × ´Ë Ô× µ
All components of Ë ¼ are assumed to be the same as in Ë unless stated otherwise.
Figure 4. Operational Semantics of SW
« Ö ÖÓÑ´«µ ÛÖÓØ ØÓ´«µ « Ö ÖÓÑ´«µ ÛÖÓØ ØÓ´«µ
Ö ´Ô ¼µ Ô Ø Ö Ø´ µ Ô ¼ Ö ÑÓÚ ´Ô ¼ ½µ Ô Ø Ö Ø´ µ¼
ÛÖ Ø ´Ô ¼µ Ô Ø Ö Ø´ µ Ò ÚÓ ´Ô ¼ ¼ µ Ô Ø Ö Ø´ µ¼
Ø ´Ô ½µ Ô Ø Ö Ø´ µ Ô Ö Ø ´Ô µ Ô Ô
×ØÓÖ ´Ô Ø Ö Ø´ µ ×ØÖÓÝ´Ô
¼ ½µ Ô ¼ ¼µ Ô Ô
Figure 5. Deﬁnitions of Ö ÖÓÑ´«µ and ÛÖÓØ ØÓ´«µ
0-7695-0665-8/00 $10.00 ã 2000 IEEE
Ë¼« ½ ËÒ is an execution, Ë¼ Ü ×Ø , and Let Ê be the cpo where ÊÊ ¾Ê and
Ë are subexecutions, then is deﬁned by
ÑÙØ Ø ´Ë¼ µ Ü Ý µÜ Ý Ü Ý¾Ê
´ ´ ½µ
ØÓÖ´« µ½ if Ö ÖÓÑ´« µ
Figure 7. The complete partial order of at-
´ otherwise tributes
ÛÖÓØ ØÓ´« µ ½ if ØÓÖ
´«½ µ ¾
ÑÙØ Ø ´ µ bilities cannot be forged, a graph traversal can be done to
ÑÙØ Ø Ñ ÙØ Ø ´Ë Ë µ «
´ ½µ ½ ½
compute whether any given resources can affect each other.
This is similar to a transitive closure, with the following
Ö ´µ added complexities:
Ü ÑÙØ Ø Ü ´ µ ¯ The resource relationships are restricted by capability
Where Ö ÖÓÑ´¡µ is deﬁned as in Figure 5.
¯ Weak capabilities modify the rights of the capabilities
Figure 6. The ÑÙØ Ø ´¡µ and Ö ´¡µ relations that are fetched through them.
¯ Some capabilities result in two-way interactions be-
tween resources, while others are one-way.
ities determine what actions are directly possible between We represent the relationship between two resources as
system resources at run time. To avoid the need for addi- an element in a complete partial order (Figure 7). If
tional run-time interpretation, it is desirable to state secu- ÐÙ
Ê , let the least upper bound of , ´ µ, be deﬁned in
rity policies in terms of information ﬂow expectations that the usual manner.
can be statically expressed. The assumed correspondence The access relationship from Ü½ to Ü¾ is the least up-
between the expected information ﬂow and the run time ex- per bound of the attributes of the capabilities that Ü½ might
ecution of the model must be veriﬁed. In this section we be able to obtain to Ü¾ . This relationship is not symmet-
formalize some notions about access rights, so that later we ric. This representation relies on the fact that if ¼ and ½
can verify: are capabilities that are identical except for possibly having
¯ that these mechanisms correspond to the actual behav- different attributes, then Ö Ø×
´ ¼µ Ö Ø×
´ ½ µ means
ior of the system, and that any operation that can be performed using ¼ can also
be done using ½ .
¯ that the algorithms used by the system services are We ﬁrst deﬁne the direct access relation between re-
correct with respect to the access control mechanism, sources, which describes the relationship between resources
in that they enforce our conﬁnement policy. in a particular state. Using this, we deﬁne the potential ac-
We are particularly interested in deriving meaningful, con- cess relation which deﬁnes the relationships that might exist
servative approximations of the set of entities that a given in the future.
subsystem might be able to mutate, and the set of entities If Ë ¾ Ë , then we deﬁne ËÖ Ç ¢ Ø
that the subsystem might gain information about. Formally, Ç Ø Ê by
if Ë ¾ Ë , and Ç Ø
, the intended meaning of
Ö Ë ´Ü Ýµ ÐÙ ÜÝ ¾ ËØµ
ÑÙØ Ð Ë ´ µ (resp. Ö Ð
Ë ´ µ) is the set of enti-
´ ´ µ
ties that directly or indirectly mutates (resp. reads) from
ËØ Ø Ö Ø´ µ Ö Ø×´ µµ
some execution beginning with state Ë . Note that the mu- ´Ó
table and readable functions are parameterized by a single Ó¾Ç Ø ¾ Ë Ô×´Óµ
state – the operating system has to be able to make these ´Ø Ö Ø´ µ Ó µ
judgments based only on the current system state, unlike Ó¾Ç Ø ¾ Ë Ô×´Óµ
the requirements which can state what happens during an Ü ¾ Ö Ø×´ µ
entire execution. One detail of the deﬁnition of Ö Ë deserves em-
The weak access right, while essential to the architec- phasis. If Ó ¾ Ç Ø has a capability , then Ó is clearly
ture, introduces signiﬁcant complication. Intuitively, one related to Ø Ö Ø´ µ. However, if conveys Ü rights,
can draw a directed, labeled graph showing the relationship this relationship is symmetric: Ø Ö Ø´ µ is also related to
between all the resources in the system. Since all interac- Ó. The intuition behind this is that interprocess communi-
tions between resources occur via capabilities, and capa- cation may authorize a reply. In our operational semantics,
0-7695-0665-8/00 $10.00 ã 2000 IEEE
a reply capability is explicitly synthesized by the ´)Ò ÚÓ Theorem 1 (Main Theorem):
If Ë¼ ½ Ë½ ËÒ is an execution, then for any
Ë¼ Ü ×Ø ,
We construct È ÓØË by using every capability indi-
cated in Ö Ë to fetch every possible capability from
ÑÙØ Ø ´Ë «
ËÒ µ Ë¼ Ü ×Ø ÑÙØ Ð Ë ´
¼ ¼ µ
Ë , obtaining a new, stronger relationship, and then
repeating: Ö ´Ë « ½
ËÒ µ Ë¼ Ü ×Ø Ö ÐË´ µ
If Ë ¾ Ë , then the potential access relation, Ë is
the limit of the series Ì¼ Ì½ Ì¾ where
Figure 8. Main veriﬁcation theorem
Ì¼ Ö Ë
Ü Ý Ì ·½ ´Ü Ýµ ÐÙ ´ Ì ´Ü Ýµ ÓÑ Ò ´Ì µ´Ü Ýµ µ If new objects could not be created, then one could merely
require that for any execution proceeding from state Ë¼ ,
If is a SW resource relationship, then ÓÑ Ò ´ µ
ÑÙØ Ø ´ µ ÑÙØ Ð Ë¼ ´ µ [and similarly for read].
Ç Ø Ç Ø
¢ Ê is deﬁned to be: What we wish to require of new objects is that no process
can use such an object to amplify its authority. However, it
ÓÑ Ò ´ µ´Ü Þµ would not be reasonable for the system to make any other a
ÐÙ ´ Ý¾Ç Ø priori assumptions about the behavior of objects that do not
such that ØÖ Ò× ××´Ü Ý Þµ µ exist. This is captured in our main theorem (Figure 8) by the
where fact that the mutated function tracks mutations that occur by
means of new objects. The intersection with Ë¼ Ü ×Ø re-
ØÖ Ò× ××´Ü Ý Þµ moves only the new objects from the set of changed objects,
if ´Ü Ý µ but not their effects on the remainder of the system.
´Ý Þµ if Ö Ü ´Ü Ýµ We ﬁrst deﬁne the set of resources that exist at a given
Û if Û Ö Ü ´Ü Ý µ Û state of the system, and then use this to state our main theo-
and Û Ö ´Ý Þ µ
otherwise Deﬁnition 2:
If Ë is a state, then Ë Ü ×Ø is deﬁned to be the following
È ÓØ subset of Ç Ø
The deﬁnition of Ë is well-deﬁned. That is, the se-
quence Ì¼ Ì½ converges.
Ë Ü ×Ø Ë Ü ×Ø Ë
Finally, with È ÓØË we can deﬁne ÑÙØ Ð and
Ö Ð (Deﬁnition 1). The lemmas that allow us to prove this theorem are
Deﬁnition 1 (The ÑÙØ Ð ´¡µ and Ö Ð ´¡µ relations): shown in Figure 10. These lemmas state the essential prop-
erties of SW which account for its security. The Execution
If Ë ¾ Ë , then
ÑÙØ Ð µË´
Reduces Authority lemma states that the power that a sub-
Ý Ü¾ ÛÖ Ü È ÓØ Ë ´Ü Ýµ
system can obtain only decreases during an execution: the
Ö Ð Ë´ µ subsystem can lose capabilities, but cannot create new ca-
Ü ÑÙØ Ð Ë ´ Ü µ pabilities that increase its authority. The number of capa-
bilities can grow, but the implied authority can only shrink.
Lemma 3: The Mutation Implies Mutable lemma states that if a re-
For all Ü Ý Ç Ø, states Ë , source becomes mutated by an operation, then it must have
previously been mutable.
ÑÙØ Ð Ë ´Üµ ÑÙØ Ð Ë ´Ýµ With these properties, the main theorem follows (Fig-
4.5. Veriﬁcation Proof Finally, we must show that the EROS constructor mech-
anism satisﬁes the conﬁnement requirements. The re-
We can now state the major theorem (Figure 8). In any quester speciﬁes at construction time a set of capabilities
execution of the system, anything that was actually mutated ÙØ ÓÖ Þ that are permitted exceptions to the conﬁne-
or read by a subsystem was considered mutable or read- ment boundary. The constructor builds a new process Ô
able by the operating system. The statement of the theo- from the set of capabilities that it is given by the builder.
rem is more subtle than one might have at ﬁrst expected. If Ë is the current state, then for all executions from Ë ,
0-7695-0665-8/00 $10.00 ã 2000 IEEE
We proceed by induction on the value of . The base case is trivial.
In the induction step, let denote the execution Ë¼ ½ Ë . Assume that for all sets ,
ÑÙØ Ø ´ Ò ½ µ Ë¼ Ü ×Ø ÑÙØ Ð Ë ´ ¼ µ
We want to show
ÑÙØ Ø ´ Òµ Ë¼ Ü ×Ø ÑÙØ Ð Ë ´ ¼ µ
This follows because:
ÑÙØ Ø ´ Òµ Ë¼ Ü ×Ø
ÑÙØ Ø «Ò Ü ×Ø
Ò ´ËÒ ËÒ µ Ë
Ñ ÙØ Ø ´ ½µ ½ ¼
´ÑÙØ Ð ËÒ ´ÑÙØ Ø ´ Ò µµ ÑÙØ Ø ´ Ò µµ ËÜ ×ØÜ ×Ø
½ ½ ½ ¼ by Lemma 5
´ÑÙØ Ð ËÒ ´ÑÙØ Ø ´ Ò µµ ÑÙØ Ð Ë ´ µµ Ë
½ ½ ¼ ¼ by induction hypothesis
´´ÑÙØ Ð Ë ´Ü ×Ø Ø ´ Ò µµ Ë Ü ×Ø µ ÑÙØ Ð Ë ´ µµ
ÑÙØ ¼ ½ ¼ ¼ by Lemma 4
ÑÙØ Ð Ë ´ÑÙØ Ð Ë ´ µµ ÑÙØ Ð Ë ´ µ
¼ ¼ ¼ induction hypothesis,
mutable() is monotonic
ÑÙØ Ð Ë ´ µ ¼ by deﬁnition
The proof that Ö and Ö Ð are related follows easily from the deﬁnitions.
Figure 9. Proof outline for main theorem
Lemma 4 (Execution Reduces Authority): from the fact that the requester initially holds no capabil-
If Ë¼ Ë½ , then for all , ities to the objects comprising the yield. When the yield
ÑÙØ Ð Ë ´ Ë¼ Ü ×Ø ÑÙØ Ð Ë ´ Ë¼ Ü ×Ø
ﬁrst begins execution, only those capabilities contained in
½ µ ¼ µ
the holes represent possible leaks to the requester. Unless
the yield consents to be inspected by transmitting capabili-
Lemma 5 (Mutation Implies Mutable): ties through one of these holes, its encapsulation is assured.
If Ë¼ Ë½ , then for all ,
5. Related Work
ÑÙØ Ø ´ ¼
Ë Ë½ µ ÑÙØ Ð Ë ´ ¼ µ
Noninterference: Rushby’s discussion of intransitive
Figure 10. Major system properties non-interference  applies a similar kind of information
ﬂow analysis to the one used here, extending earlier work
by Haigh and Young  and by Goguen and Meseguer .
conﬁnement requires that That formulation is more general than the technique used
ÑÙØ Ø Ô ´ µ ÑÙØ Ð Ë ´ ÙØ ÓÖ Þ µ
here, but would require extension to deal with systems in
which access rights are transferable. In particular, there is
The constructor requires that ÓÐ × ÙØ ÓÖ Þ , and no provision in the Rushby formulation for the actions of
therefore requires (by Lemma 3) that ÑÙØ Ð Ë ´ ÓÐ ×µ
the step function to revise the security assertions as access
ÑÙØ Ð Ë ´ ÙØ ÓÖ Þ µ. In other words, the client has rights are legitimately propagated or mandatory constraints
stated permission for information to ﬂow via the holes. Pro-
vided the non-holes do not leak information, the “yield” of PSOS: Neumann et al. constructed extensive proof syn-
the constructor is properly sandboxed. thesis mechanisms in connection with PSOS . While a
With the main theorem, this is easy to show. The con- proof sketch of the security properties of this system was
structor is very conservative – the capabilities it consid- included in the report, no proof of correctness for conﬁne-
ers as “safe” are those which will add no elements to ment in the PSOS system has been published. The proof
ÑÙØ Ð ´Ôµ. The only other capabilities it gives Ô are sketched in the report fails to demonstrate that the opera-
members of the authorized set, so the statement of correct- tional semantics of the system architecture actually satisﬁes
ness follows immediately from the theorem. the speciﬁcation.
The encapsulation of the constructor “yield” follows Mandatory Policy Enforcement: Boebert  and
0-7695-0665-8/00 $10.00 ã 2000 IEEE
Karger  show that pure capability systems cannot enforce quently, there is no need to consider transitively accessible
the *-property. While their conclusion is correct, capability mutation rights. Were such a capability introduced, some
systems do provide sufﬁcient strength to construct manda- variant of theÛ right described here would be required.
tory policies at a higher level of abstraction with reasonable By permitting the client to authorize exceptions to the
performance, as has been done in KeySafe . immutability constraint, the conﬁnement policy deﬁned
Karger has also shown that unmodiﬁed capability sys- here slightly extends the memoryless execution policy. By
tems cannot enforce the conﬁnement policy . The appar- permitting recursive use of constructors that produce con-
ent discrepancy results from differences in term deﬁnition. ﬁned subsystems, the conﬁnement policy enables a form of
Karger’s conﬁnement policy is a mandatory access control object-based software construction that is not possible un-
policy: “this piece of information must not be disclosed der the memoryless execution constraint. Recursive con-
to that set of unauthorized parties.” That is, it is a policy struction enables EROS to bootstrap “copy on write” ad-
concerning the ﬂow of information to subjects. Lampson’s dress spaces, and can therefore be used to perform object
conﬁnement problem  imposes a weaker constraint: in- instance creation. The most common use of the EROS con-
formation can ﬂow out of the subsystem only through au- structor is to create new process instances in this way.
thorized channels. That is, in the Lampson deﬁnition the Jones also proposes a rights ampliﬁcation operation that
channels deﬁne an encapsulation boundary to be enforced. must be handled with considerable care, lest the supposedly
KeySafe: The KeySafe system  implements a ref- restricted subsystem gain mutate rights in unforeseen ways.
erence monitor that mediates interactions across compart- Amplify operations appear to have been excluded from the
ments. Each compartment is a conﬁned subsystem created systems veriﬁed in the thesis.
by the reference monitor. Creating compartments in this
fashion ensures that no unauthorized channels out of the 6. Conclusion
compartment exist, and also that no inspection of the com-
partment contents is permitted. We have speciﬁed the security requirements and opera-
Compartments in KeySafe can be used to encapsulate tions of a real operating system, and provided a formal def-
security levels, users, intersections of level and user, or inition for one security policy: conﬁnement. We have de-
any other entity that the security policy wishes to describe. veloped a methodology and proof structure for this policy,
The granularity of policy enforcement under KeySafe is the and shown that it is enforced. This methodology general-
compartment rather than the process. izes to information ﬂow problems in many capability-based
Where the security policy permits transfer of capabilities architectures. The constructor implementation performs the
from one compartment to another, the reference monitor conﬁnement check in no worse than Ò ÐÓ Ò time, where Ò
substitutes a capability to a transparent forwarding object is the number of holes known to the constructor. Construc-
to allow later revocation. This is similar to the indirection tion is signiﬁcantly faster than the equivalent UNIX fork
mechanism proposed by Redell . Cross-compartment and exec combination .
calls are relatively rare, and the overhead of this indirection The SW model faithfully captures EROS. This was not
(once established) is low. Intracompartment invocations in- accidental; both EROS and KeyKOS intentionally provide
cur no overhead from the reference monitor. as “pure” a model as the architects could contrive to build.
We believe that the KeySafe architecture can enforce Related work on the EROS implementation has demon-
both the *-property and Karger’s conﬁnement policy, but strated that a pure capability system of this form can be
this does not directly contradict their claims. KeySafe is a made to perform quite well [19, 20].
reference monitor built on top of a more primitive capability Veriﬁcations such as this one have considerable practi-
mechanism; such a reference monitor constitutes a modiﬁed cal utility. SW’s operational semantics was constructed by
capability system in the sense of Karger’s discussion. reducing the behavior of a real system to a manageable col-
Memoryless Execution: Jones’ dissertation  discusses lection of primitives. Constructing the operational seman-
computing a closure containing all protection states that tics revealed an implementation error in the real system. It
can be derived from an initial protection state by the per- also enabled the architecture to be signiﬁcantly improved
formance of “environment transforming functions.” She by providing a clear identiﬁcation of those aspects of the
demonstrates the enforcement of a number of security poli- semantics that were truly essential to security. Best of all, it
cies using this sort of transitive closure, including a “Memo- did so at modest cost.
ryless Execution” policy closely related to our conﬁnement The Execution Reduces Authority lemma provides a
policy. The memoryless execution policy allows the called powerful simplifying tool in analyzing security issues. Both
procedure to modify its parameters, but does not allow mod- the statement of requirements and the corresponding proof
iﬁcation of other objects. There appears to be no capability are drastically more complicated in systems that permit am-
in Jones’ model that names environments directly. Conse- pliﬁcation of authority. Indeed, this lemma seems worth
0-7695-0665-8/00 $10.00 ã 2000 IEEE
adopting as a basic principle of operating system design.  A. K. Jones. Protection in Programmed Systems. PhD thesis,
Capabilities provide two characteristics that are essential Carnegie-Mellon University, 1973.
to the proof structure we have adopted. First, they combine  P. Karger. Improving Security and Performance for Capa-
denotation and access rights into a single entity, which al- bility Systems. PhD thesis, University of Cambridge, Oct.
lows straightforward construction of the mutable and read- 1988. Technical Report No. 149.
able relations. Second, they are unforgeable, which guaran-  P. A. Karger and A. J. Herbert. An augmented capability
tees that this construction is closed. An equivalent security architecture to support lattice security and traceability of ac-
analysis for ACL-based systems would be more complex: cess. In Proc. of the 1984 IEEE Symposium on Security and
modiﬁcations to a given resource’s access control list have Privacy, pages 2–12, Oakland, CA, Apr. 1984. IEEE.
non-local consequences in the accessibility graphs, and may  B. W. Lampson. A note on the conﬁnement problem. Com-
violate the closure. munications of the ACM, 16(10):613–615, 1973.
Capability systems provide a natural framework for  C. R. Landau. The checkpoint mechanism in KeyKOS. In
typed, protected objects. Component architectures such as Proc. Second International Workshop on Object Orientation
COM and CORBA are increasingly used for critical sys- in Operating Systems, pages 86–91. IEEE, Sept. 1992.
tems. Applications constructed using these technologies
 J. Liedtke. Improving IPC by kernel design. In Proc. 14th
may be viewed as subsystems connected by capabilities. We
ACM Symposium on Operating System Principles, pages
expect that forthcoming e-Commerce applications will be 175–188. ACM, 1993.
built using similar application frameworks. Therefore, se-
 P. G. Neumann, R. S. Boyer, R. J. Feiertag, K. N. Levitt, and
curity policy enforcement in capability systems is a critical
L. Robinson. A provably secure operating system: The sys-
area of future research. tem, its applications, and proofs. Technical Report Report
CSL-116, Computer Science Laboratory, may 1980.
7. Acknowledgements  S. A. Rajunas. The KeyKOS/KeySAFE system design.
Technical Report SEC009-01, Key Logic, Inc., Mar. 1989.
Norm Hardy, the principal architect of KeyKOS, ﬁrst http://www.cis.upenn.edu/˜KeyKOS.
suggested the need for this proof and its feasibility. Carl  D. D. Redell. Naming and Protection in Extensible Operat-
Gunter, Jonathan Smith, and Insup Lee of the University of ing Systems. PhD thesis, University of California at Berke-
Pennsylvania provided comments and feedback on this pa- ley, 1974.
per at various stages. Maria Ebling, Stephen Holton, Guer-  J. R. Rushby. Noninterference, transitivity, and channel-
ney Hunt, and Paul Karger of IBM also provided extensive control security policies. Technical Report CSL-92-02,
feedback, as did Chris Okasaki of Columbia University. Computer Science Laboratory, SRI International, Dec. 1992.
 J. S. Shapiro. The EROS Object Reference Manual.
References  J. S. Shapiro. EROS: A Capability System. PhD thesis, Uni-
versity of Pennsylvania, Philadelphia, PA 19104, 1999.
 W. E. Boebert. On the inability of an unmodiﬁed capability
 J. S. Shapiro, D. J. Farber, and J. M. Smith. The mea-
machine to enforce the *-property. In Proc. 7th DoD/NBS
sured performance of a fast local IPC. In Proc. 5th Inter-
Computer Security Conference, pages 291–293, Gaithers-
national Workshop on Object Orientation in Operating Sys-
burg, MD, USA, Sept. 1984. National Bureau of Standards.
tems, pages 89–94, Seattle, WA, USA, Nov. 1996. IEEE.
 A. C. Bomberger, A. P. Frantz, W. S. Frantz, A. C. Hardy,
N. Hardy, C. R. Landau, and J. S. Shapiro. The KeyKOS  J. S. Shapiro, J. M. Smith, and D. J. Farber. EROS: A fast
nanokernel architecture. In Proc. USENIX Workshop on capability system. In Proc. 17th ACM Symposium on Op-
Micro-Kernels and Other Kernel Architectures, pages 95– erating Systems Principles, pages 170–185, Kiawah Island
112. USENIX Association, Apr. 1992. Resort, near Charleston, SC, USA, Dec. 1999. ACM.
 W. Frantz, C. Landau, and N. Hardy. Gnosis: A secure op-  J. S. Shapiro and S. Weber. Verifying operating system secu-
erating system for the ’90s. SHARE Proceedings, 1983. rity. Technical Report MS-CIS-97-26, University of Penn-
sylvania, Philadelphia, PA, USA, 1997.
 J. A. Goguen and J. Meseguer. Inference control and un-
winding. In Proc. Symposium on Security and Privacy,
pages 75–86, Oakland, CA, USA, Apr. 1984. IEEE Com-
 J. Haigh and W. Young. Extending the noninterference ver-
sion of mls for sat. IEEE Transactions on Software Engi-
neering, 13(2):141–150, Feb. 1987.
 N. Hardy. The KeyKOS architecture. Operating Systems
Review, pages 8–25, Oct. 1985.
0-7695-0665-8/00 $10.00 ã 2000 IEEE