Sandbox System Call API for Linux
This project was created by me (Dave Peterson) while I was a graduate student
in Computer Science at the University of
California, Davis. It served as my master's thesis. The goals were to
design a system call API that serves as a simple yet powerful mechanism for
confining untrusted programs, and to develop a prototype implementation for
I finished working on the project in late 2002 and submitted my master's
thesis in early 2003. Since then I have left the university and taken a
software development job in the San Francisco Bay Area. Although I no longer
work on the project, the code is available for download. The prototype is
mostly finished. However, the code needs a good deal of cleanup and privilege
checking kernel hooks are present in only a limited number of places. Anyone
who is interested in picking up where I left off is welcome to do so.
The sandbox system call API is conceptually similar to chroot() and
BSD jails. However, it has much greater flexibility and expressive power.
Here are some of its key features:
My master's thesis provides a more complete description of the design and its
My master's thesis provides a detailed discussion of ideas for future
improvements. Below are brief high-level descriptions of a couple of ideas:
Design and implement a mechanism that allows transitions between sandboxes
as a result of executing certain programs. Conceptually, this is somewhat
similar to domain and type enforcement. In other words, sandboxes may be
viewed as domains, and sets of privileges (defined by components) may
function in a manner similar to types.
Since sandboxes may be nested, one can imagine a mechanism that allows
transitioning behavior to be defined independently at multiple levels of a
sandbox hierarchy. Thus, transitioning behaviors may simultaneously
enforce mandatory access controls near the top of a hierarchy and
discretionary access controls at deeper levels.
Design and implement a new type of component that governs file access
according to device/inode. This component would complement the File
System Component specified by the current design (which defines privileges
according to pathnames). It could perhaps function by binding
privilege-related tags to inodes. A user or system administrator could
statically create the bindings. Alternately, the sandboxing mechanism
could create them dynamically according to pathname-based rules when a
file is created or opened.
For filesystems with extended attributes, the attributes could potentially
provide storage for the tags. For filesystems that do not provide
extended attributes, another storage mechanism would need to be developed.
Potentially, tag-related information could be stored in a special file
that the sandboxing mechanism creates and carefully guards.
Currently, the best documentation available is my master's thesis
There is also a paper
[BIBTEX] that I presented at the
11th USENIX Security
Symposium in San Francisco (August 5-9, 2002).
Obtaining the Code
Click here to obtain the source code.
My email address is dave at dspeterson dot com.