This document summarizes the Capsicum paper, which presents an API and implementation for application sandboxing on FreeBSD using capabilities. The key points are: 1) It introduces libcapsicum which provides APIs to enter capability mode and assign capabilities to file descriptors to restrict access. 2) Capabilities wrap file descriptors and allow fine-grained access control over operations like read, write, seek. 3) The implementation modifies the kernel to enforce capabilities during operations like path lookups and descriptor access. 4) It applies the API to applications like tcpdump, dhclient, gzip and the Chromium browser to demonstrate sandboxing with minimal code changes.

1. Capsicum: Practical Capabilities for
UNIX
Robert N. M. Watson, Jonathan Anderson, Ben
Laurie, Kris Kennaway
Presented by : Ruchith Fernando
CS 626
March 8, 2011

2. Context
● Multiple processes of an application
● Ambient user privileges
● Full power of the user
● Access to all resources

3. Browser

4. Browser
/home/bob/.browser_settings/
/home/bob/personal/
/home/bob/work/
/bin/
/proc/
/dev/
Operating System

5. Least Privilege

6. Application Sandboxing
(Compartmentalization)

7. Problem Statement
● How can the OS support application
sandboxing?
● Minimize the effort by the developers?
● Better performance compared to other
techniques.

8. Contribution
● API extensions to break down application code
● Run them in sanboxes
● Logical application
● Implementation – FreeBSD
● To be included in version 9
● Application of the extensions
● Performance evaluation

9. Main Idea
● API extensions
● libcapsicum
● Capability mode
● Capabilities

10. Capability Mode
● No access to global namespaces
● Process ID, File paths, File systems ID, System
clocks, etc.
● Restricted access to some syscalls
● sysctl (only 30 params are allowed)
● shm_open
● openat …
● No privilege elevation via setuid/setgid

11. Capabilities
● Wraps normal file descriptors
● cap_new(FD, mask_of_rights);
● 60 possible mask rights
● CAP_READ
● CAP_WRITE
● CAP_SEEK
● ...
● Directories

13. Implementation
● At kernel services
● namei – path lookups
● fget – File descriptors to struct file refs
● pdfork() – returns a file descriptor
● Runtime
● fexecve()
● rtld­elf­cap – Capability aware linker
● fdlists – to declare capabilities to be passed in

14. Can we use it?

15. Debugging
● procstat
● State of ruining processes
● Shows
– capability mode
– Capability rights masks
● Missing dependencies
● ENOTCAPABLE
– New errno value
● API to check whether sandboxing is enabled

16. tcpdump
● cap_enter()
● Restricting access to STDIN, STDOUT,
STDERR Using lc_limitfd()
● Problem with lazy DNS resolution
● Need to access /etc/resolv.conf

17. dhclient
● Before : chroot + setuid
● Now : cap_enter()
● Problems
● Holds write access to the lease db
● Can submit msgs to logs

18. gzip
● Three core functions
● Passed input and output capabilities (FDs)
● CAP_READ, CAP_WRITE, CAP_SEEK
● pdfork() and fexecve()
● Changes were small (406 LOC) but non-trivial
(16%)

19. Chromium
● A renderer process per browser tab
● lc_limitfd() to limit access to FDs
● pak files
● stdio
● /dev/random
● Font files
● cap_enter()

20. Chromium Comparison
Operating Model Line Description
system count
Windows ACLs 22350 Windows ACLs and SIDs
Linux chroot 605 setuid root helper sandboxes renderer
Mac OS X Seatbelt 560 Path-based MAC sandbox
Linux SELinux 200 Restricted sandbox type enforcement domain
Linux seccomp 11301 seccomp and userspace syscall wrapper
FreeBSD Capsicum 100 Capsicum sandboxing using cap enter

21. Evaluation

22. Evaluation
vfork() has the least overhead

23. Evaluation
Run time per gzip invocation with random data

24. Related work
● MAC and DAC
● Micro-kernels

25. Limitations
● The amount of effort depends strictly on the
design of the application
● gzip 409 LOC Vs. Chromium 100
● Security Policy embedded in code
● No easy access to policy spec

28. Thank You