Sandbox System Call API for Linux

Introduction

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.

Design Overview

• Sandboxes may be safely created and manipulated by either trusted or untrusted users and programs.

• Sandboxes may be dynamically reconfigured at runtime. Any changes made to the privileges associated with a given sandbox have an immediate effect on processes executing inside.

• Privileges are specified in a fine-grained manner, and are grouped into components that serve as modular, reusable building blocks for construction of customized protection domains. Components group related privileges together according to different areas of system functionality (file access, device I/O, network access, signals, etc.).

• A set-theoretic approach to privilege specification has been taken. Specifically, components are viewed as sets of privileges that may be manipulated using set-theoretic primitives. Given any two components x and y of the same type (i.e. two file system components), a new component may be constructed that represents any of the following:
  • the union of the sets of privileges represented by x and y

  • the intersection of the sets of privileges represented by x and y

  • the complement of the set of privileges represented by either x or y

  This allows construction of protection domains whose privileges satisfy assertions relative to each other given by arbitrary set-theoretic primitives.

• Sandboxes may be nested hierarchically for simultaneous enforcement of security policies at different levels of granularity. Privileges at any level of a hierarchy may be manipulated independently. Mandatory and discretionary access controls may be simultaneously enforced.

• Sandboxes may be configured so that a sandboxed process will block when it attempts certain actions rather than being immediately denied a given privilege. When a process blocks in this manner, an event is generated and placed in an event queue associated with the sandbox. A process with authority over the sandbox may retrieve the events and decide individually which actions to allow. The set of attempted actions that trigger the blocking mechanism may be specified in a fine-grained manner using the set-theoretic primitives described above, and is dynamically reconfigurable at runtime.

Future Work

• 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.

Documentation

Obtaining the Code

Contact Information

Home