Lecture: Capsicum

Capsicum: practical capabilities for UNIX, USENIX Security 2010

Discussion lead: Nate Yazdani

Questions

• Consider applying Capsicum to sandboxing a web server. The web server needs to perform DNS resolving by accessing /etc/resolv.conf and generate random numbers through /dev/random. List possible problems and the necessary modifications to the original web server.

• Why is cap_new so much slower than dup, even though they seem to perform similar tasks?

• Using Capsicum means programmers can compartmentalize their applications, by partitioning an application into multiple processes. List possible programming burdens and mitigation of this programming model. For instance, does it make debugging harder? Does it impact performance? Does it affect management of subprocesses (e.g., one needs to quit all of them at once when exiting the application)? Feel free to come up with your own concerns.

• In implementation terms, why does it make sense for Capsicum to add a distinct capability structure in the kernel instead of just adding fields to the file structure?

• List any questions and/or comments that you have about Capsicum or the paper.

Background

• threat model
  • what’s the problem capsicum tries to solve?
  • applications have bugs
    • assume compromise after some point
    • esp. with network-facing parts: browsers, servers, …
  • not arbitrary/malicious applications
• sandboxing
  • high-level idea: break up into smaller compartments
  • secure each (or the most vulnerable) compartment
  • confine damage to one compartment (ideally w/ least privilege)
  • real-world examples?
• sandboxing plans
  • physical isolation
  • virtual machine: good isolation; hard to share; perf
  • discretionary access control (DAC)
  • mandatory access control (MAC)
  • capability - not Linux capabilities CAP_* (partition root)
• DAC
  • discretionary: users can call chmod (e.g., unix)
  • object ACLs: unix file permissions
  • processes privileges: uid
  • check a process’s privilege when it accesses an object
  • sandbox: create separate principals (Android: each app in its own uid)
  • root required for: creating new principals, chroot
  • processes: the confused deputy
• MAC
  • centrally controlled security policies
  • examples
    • Linux: AppArmor, SELinux
    • macOS: Seatbelt (from TrustedBSD MAC) - see profiles under /usr/share/sandbox/
    • Windows: Mandatory Integrity Control
• capability
  • pure capability-based systems?
  • how to integrate with UNIX
  • how to work with existing namespaces: file system, fd, pid, network, uid