application state. This approach would allow sandboxed
video processing in unmodified Web browsers. However,
library APIs are often not crafted for sandbox-friendliness:
one reason we placed separation in gzip rather than libz
is that whereas gzip internal APIs used file descriptors,
libz APIs acted on buffers. Forwarding capabilities offers
full I/O performance, whereas the cost of transferring buffers via RPCs grows with file size. This approach does not
help where vulnerabilities lie in library API use; for example, historic vulnerabilities in libjpeg have centered on
callbacks into applications.
4. 4. chromium
Google’s Chromium Web browser uses a multiprocess logical application model to improve robustness. 13 Each tab is
associated with a renderer process that performs the complex
and risky task of rendering page contents through parsing,
image rendering, and JavaScript execution. More recently,
Chromium has integrated sandboxing to improve resilience
to malicious attacks using a variety of techniques (Section 5).
The FreeBSD port of Chromium did not include sandboxing, and the sandboxing facilities provided as part of the
similar Linux and Mac OS X ports bear little resemblance to
Capsicum. However, existing compartmentalization was a
useful starting point: Chromium assumes sandboxes cannot open files, certain services were already forwarded to
renderers (e.g., font loading via passed file descriptors and
renderer output via shared memory).
Roughly 100 lines of code were required to constrain file
descriptors passed to sandboxes, such as Chromium pak files,
stdio,/dev/random, and font files, to call cap_enter(),
and to configure capability-oriented POSIX Shared memory
instead of System V IPC shared memory. This compares favorably with 4. 3 million lines of Chromium source code, but would
not have been possible without existing sandbox support.
5. sanDBoX coMPaRison
Chromium provides an ideal context for a comparison with
existing sandboxing mechanisms, as it employs six different
sandboxing technologies (Table 2). Of these, two are DAC-based, two MAC-based, and two capability-based.
5. 1. Windows acLs and siDs
On Windows, Chromium employs DAC to create sandboxes. 13 The unsuitability of inter-user protections for
the intra-user context is well demonstrated: the model is
both incomplete and unwieldy. Chromium uses Access
Control Lists (ACLs) and Security Identifiers (SIDs) to
Table 2. sandboxing mechanisms employed by chromium.
sandbox renderers on Windows. Chromium creates a SID
with reduced privilege, which does not appear in the ACL of
any object, in effect running the renderer as an anonymous
user, and attaches renderers to an “invisible desktop,” isolating them from the user’s desktop environment. Many
legitimate system calls are denied to sandboxed processes.
These calls are forwarded to a trusted process responsible
for filtering and processing, which comprises most of the
22,000 lines of code in the sandbox module.
Objects without ACL support are not protected, including FAT FSs and TCP/IP sockets. A sandbox may be unable to
read NTFS files, but it can communicate with any server on
the Internet or use a configured VPN. USB sticks present a
significant concern, as they are used for file sharing, backup,
and robustness against malware.
5. 2. Linux chroot
Chromium’s Linux suid model also attempts to create a
sandbox using legacy access control; the result is similarly
porous, but with the additional risk posed by the need for OS
privilege to create the sandbox. In this model, access to the
filesystem is limited to a directory via chroot(): the directory becomes the sandbox’s virtual root directory. Access
to other namespaces, including System V shared memory
(where the user’s X window server can be contacted) and network access, is unconstrained, and great care must be taken
to avoid leaking resources when entering the sandbox.
Invoking chroot() requires a setuid binary helper
with full system privilege. While similar in intent to
Capsicum’s capability mode, this model suffers from significant weakness (e.g., permitting full access to the System
V shared memory as well as all operations on passed file
descriptors).
5. 3. Mac os X sandbox
On Mac OS X, Chromium uses Apple’s Sandbox system.
Sandbox constrains processes according to a scheme-based
policy language5 implemented via the MAC Framework. 19
Chromium uses three policies for different components,
allowing access to font directories while restricting access
to the global FS namespace. Chromium can create stronger
sandboxes than is possible with DAC, but rights granted to
renderer processes are still very broad, and policy must be
specified independently from code.
As with other techniques, resources are acquired before
constraints are imposed, so care must be taken to avoid leaking resources into the sandbox. Fine-grained file system constraints are possible, but other namespaces such as POSIX
os
Windows
linux
mac oS X
linux
linux
FreeBSd
Model
ACls
chroot()
Sandbox
Selinux
seccomp
Capsicum
Loc
22,350
605
560
200
11,301
100
Description
Windows ACls and Sids
setuid() root helper sandboxes renderer
Path-based mAC sandbox
restricted sandbox domain
seccomp and userspace syscall wrapper
Capsicum sandboxing using cap_enter()
fs
!
✓
✓
✓
!
✓
iPc
!
✗
!
!
!
✓
net
✗
✗
✓
✓
✓
✓
s π s’
✗
✓
✓
✗
✓
✓
Priv
✓
✗
✓
✗
✓
✓
