Intro to Capsicum by pjd
Problem of too many capabilities (overflowing 64 bits)
Debate about the best name for rights
New cap_rights_set() macro means the new capability representation takes the same amount of code space as the old ORing of bits.
libcapsicum provides services over capabilities with a libnv api
libcasper provides friendly interfaces to services, for example cap_getaddrinfo()
services include: psystem.dns, system.filesystem, system.grp, system.pwd, system.rnadom, system.socket, and system.sysctl
lots of newly sandboxes code: auditdistd, dhclient, file, libmagic, hastctl, hastd, kdump, …
Some functions such as localtime need some preparation before they can be called in capability mode. localtime() can simply be called once.
Some discussion of a lack documentation of capsicum syscall limitations. Robert suggests solaris thread-safety manpage entries.
hrs asks what happens when casper dies. Answer: bad things. What happens if you runtime linker dies? Lots of tradeoffs available such as one per application, one per user, one per system, etc. This will likely be a tradeoff of trustworthiness vs performance initially.
speculation on how many past vulnerabilities are gone or impractical if you sandbox most unix pipe tools.
sbz asks if an external profiles could be used in place for code modifications: pjd responds that profiles can become out of date. rwatson comments that as we move toward casper being a runtime linker we can start analyzing binaries post build to see what services they declared what they used. Warren suggests that static declaration of rights may not scale beyond some level of complexity. rwatson points out that this is a deliberately code oriented view of privilege, at least somewhat in response to the infinitely long sets of SELinux rules that are both usually out of date and impossible to audit.