David S' Peterson, Matt Bishop, and Raju Pandey

1
A Flexible Containment Mechanism for Executing
Untrusted Code
David S. Peterson, Matt Bishop, and Raju
Pandey May 8, 2002
2
Disadvantages of UNIX Security Model

• Deals with users/groups but not individual
  programs
• Users need protection against Trojan horses
• Servers often exploitable (example CGI scripts)
• Users/groups may be created for individual
  programs
• Setting them up is too much work
• Complexity increases with number of programs
• Root privileges are required
• Root privileges are dangerous
• All or nothing
• Setuid programs often exploitable

3
More Disadvantages of UNIX Model

• Changing user privileges is inconvenient
• Supplementary groups are too coarse-grained
• Changing settings on large groups of files is
• -cumbersome and dangerous
• It requires too much work
• Correctness of settings is hard to verify
• User restrictions may overlap

4
Sandboxing Mechanisms

• Specify security policies for individual programs
• Confine programs so that policies are enforced

Untrusted Program
Unsafe Resource
Safe Resource

• Java virtual machine is a well-known example

5
Advantages of Sandboxing Mechanisms

• Support for program-specific fine-grained
  security policies
• Support for safe execution of downloaded or COTS
  software
• Upper bounds on privileges easily determined
• System security easily verified
• If implemented properly, can guard against
  attacks on setuid programs
• If implemented properly, can be safely created
  and modified by unprivileged users

6
Limitations of Previous Designs

• Java sandboxes support only Java programs
• Recent OS-based mechanisms have limitations
• Configuration typically requires a trusted user
• Creating or changing a sandbox is usually
  difficult -and may require loading custom code
  into kernel
• Not designed for cases where required privileges
  -are not known in advance
• Some designs use active monitoring processes
• Privilege checks require context switches
• Monitoring process may be required to fork each
  time sandboxed process forks
• Monitoring process may be vulnerable

7
Overview of Our Design

• Modified OS kernel provides general-purpose
  system call API for sandboxing
• Sandboxes are passive, kernel-resident entities
• Privilege checks do not require context switches
• Privilege checks may occur deep within kernel
• Kernel-resident objects are hard to tamper with
• No explicit sandbox destroy operation resources
  held by unused sandboxes reclaimed automatically
• Principle of attenuation of privileges is
  followed
• Mechanism is less error-prone
• Untrusted users may create/change sandboxes

8
Sandboxes are Dynamic

• May be modified as programs execute inside
• May be configured so that some attempted actions
  will block sandboxed processes
• Useful if required privileges are initially
  unknown
• May be useful for intrusion detection
• Allows any combination of passive/active
• monitoring
• Some privileges may be dynamically revoked
• Easy to create and configure on demand
• Customized sandboxes for downloaded code
• Servers may be secured against external attack

9
Modular, Extensible Design

• Privileges are organized into components

dev
fs
ptrace
sig
ipc
sys
net
sandbox

• New components may be derived from existing ones
  using set-theoretic operations
• As new OS features are added, corresponding
  component types may be created

10
Manipulating Components

• Components may be manipulated using set-theoretic
  transformations. Advantages
• Highly expressive
• Inter-component relationships well understood
• Uniformity of mechanism
• May be used to answer questions such as Which
  privileges are granted to user A or B but denied
  to user C?
• Facilitates verifying that policies are correctly
  enforced

11
Sandboxes May be Nested
A
B1
B2
C2
C1

• Privilege checks must pass at each level
• Security policies may span a spectrum from global
  to local
• /sbin/init may be sandboxed at boot time
• User login shells may be sandboxed
• Users may launch programs inside sandboxes
• Programs may use them for dropping privileges

12
Future Work

• Guard against DoS attacks
• Allow revocation of open file descriptors
• Provide portability across operating systems
• Allow sandboxes to have more permanence
• Allow execution of certain programs to cause
  transitions between sandboxes
• Extend sandboxing model to a distributed system