- Files and Processes
- File Descriptors as Capabilities / Exposing Directories
- Privileged Daemons / The Future of Capsicum
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Privileged Daemons
One of the core ideas of Capsicum is that you should always run at the minimum level of privilege required to do what you need to do and ask for elevated privilege when it isn't enough. While the core functionality of Capsicum is done, a lot of the ongoing work focuses on allowing elevated privilege more easily. In the example above, it would be much more convenient to have a reusable function along the lines of mkstmp() that would ask another process of a temporary file. Ideally, the daemon that created it could then remove it once the process using it had exited.
There is a lot of potential for daemons like this. The cryptographic code in OpenSSL, for example, is very complex and prone to errors. It would be convenient for a lot of programs to be able to open encrypted sockets (or even files), where all of the cryptographic code ran in a completely unprivileged sandbox.
For graphical applications, it's useful to have something slightly more privileged that can pop-up file dialogs and pass file descriptors into the program, granting it the ability to open or save user-selected files. Passing file descriptors is something that can already be done via SCM_RIGHTS with UNIX domain sockets, and capability file descriptors are no different in this respect.
Part of the advantage of Capsicum is that it is relatively simple to use. Part of the original work on it involved porting the Chromium web browser's sandboxing implementation to use Capsicum. This already has several implementations, with the most complex being the Windows version requiring 22,350 lines of code. The Capsicum version required a mere 100.
The second simplest used SELinux (200 lines), but this did not include the very long SELinux policy. The SELinux version also had significant drawbacks because it was very easy for the code and policy to get out of sync. If this happened, the maintainers only noticed if the policy were too strict, not if it were too loose, which is exactly the opposite of how it should be.
The Future of Capsicum
There's a lot of potential for Capsicum to make FreeBSD an even more secure system than it already is. One of the current projects involves closer integration with the run-time linker (rtld), which is responsible for launching applications that use shared libraries. This is important because, ideally, you'd like rtld to be responsible for entering capability mode before you even run things like static constructors—that is, before main() runs. Ideally, part of this would involve setting up existing file descriptors, with specific rights, pointing to specific files or sockets on launch.
By the time FreeBSD 10 arrives, Capsicum is likely to be enmeshed in most of the programs in the base system. Some are simple. UNIX filter programs can typically just call cap_enter() on startup: They read from standard input and write to standard output, and should not be allowed to touch anything else. Others are more complex.
Adding a set of helper libraries and daemons will also make it easier for third-party code to work in a Capsicum environment, so hopefully more external packages will start to support it, too. I plan on spending some time over the next year making it easy for GNUstep applications to make use of Capsicum, and I hope that other developers will do the same.