It’s been a busy year for Capsicum, practical capabilities for UNIX, so a year-end update seemed in order:
The FreeBSD Foundation and Google jointly funded a Capsicum Integration Project that took place throughout 2013 — described by Foundation project technical director Ed Maste in a recent blog article. Pawel Jakub Dawidek refined several Capsicum APIs, improving support for ioctls and increasing the number of supported capability rights for FreeBSD 10. He also developed Casper, a helper daemon that provides services (such as DNS, access to random numbers) to sandboxes — and can, itself, sandbox services. Casper is now in the FreeBSD 11.x development branch, enabled by default, and should appear in FreeBSD 10.1. The Google Open Source Program Office (OSPO) blog also carried a September 2013 article on their support for open-source security, featuring Capsicum.
Capsicum is enabled by default in the forthcoming FreeBSD 10.0 release — capability mode, capabilities, and process descriptors are available in the out-of-the-box GENERIC kernel. A number of system services use Capsicum to sandbox themselves — such as the DHCP client, high-availability storage daemon, audit log distribution daemon, but also command-line tools like kdump and tcpdump that handle risky data. Even more will appear in FreeBSD 10.1 next year, now that Casper is available.
David Drysdale at Google announced Capsicum for Linux, an adaptation of Linux to provide Capsicum’s capability mode and capabilities, in November 2013. David and Ben Laurie visited us in Cambridge multiple times this year to discuss the design and implementation, review newer Capsicum APIs, and talk about future directions. They hope to upstream this work to the Linux community. Joris Giovannangeli also announced an adaptation of Capsicum to DragonFlyBSD in October 2013.
Over the summer, Mariusz Zaborski and Daniel Peryolon were funded by Google Summer of Code to work on a variety of new Capsicum features and services, adapting core UNIX components and third-party applications to support sandboxing. For example, Mariusz looked at sandboxing BSD grep: if a vulnerability arises in grep’s regular-expression matching, why should processing a file of malicious origin yield full rights to your UNIX account?
In May 2013, our colleagues at the University of Wisconsin, Madison, led by Bill Harris, published a paper at the IEEE Symposium on Security and Privacy (“Oakland”) on “Declarative, Temporal, and Practical Programming with Capabilities” — how to model program behaviour, and automatically transform some classes of applications to use Capsicum sandboxing. We were very pleased to lend a hand with this work, and feel the art of programming for compartmentalisation is a key research challenge. We also collaborated with folk at SRI and Google on a a workshop paper developing our ideas about application compartmentalisation, which appeared at the Security Protocols Workshop here in Cambridge in March 2013.
Google and the FreeBSD Foundation are committed to further work on Capsicum and its integration with applications, and research continues on how to apply Capsicum at several institutions including here at Cambridge. We hope to kick off a new batch of application adaptation in coming months — as well as integration with features such as DNSSEC. However, we also need your help in adapting applications to use Capsicum on systems that support it!
In my tenure as a security engineer I have often wondered if something more “usable” than SELinux will be created and exist.
This sounds promising as it provides a sensical approach to the basic levels of commands. eg. the use of grep yielding root like privs.
With most of my SELinux implementations, they are tiresome, the assessors don’t understand SELinux policy creation and methods are argued on how best to implement. etc.
I’ve often wondered if the NSA put a security hole in SELinux, and then I realized that if they just made SELinux hard to set up and use then many people would misconfigure it, and/or wouldn’t take the time to really explore its nooks and crannies. Plus, after getting fed up with SELinux, they might not have the energy to pursue some other security solution.
It’s important to note that everyone has been entirely suspicious of SELinux since the very beginning. It is also important to note that the NSA is not nearly a homogenous organization, it’s a Government Agency. It is filled with all types, including greedy squabbling bureaucrats. The SSL pressure, the various hax and other things demonstrate a type of competence which is direct and easily focussed while depending on conspiratorial privacy. Backdooring a broad security measures in The Kernel, while possible, is extremely unlikely. So many eyes reviewing and testing the code, it would be almost impossible.
I do not know their purpose, but I think it was a legitimate project and it probably does work, particularly in embedded / tightly controlled environments.
Interestingly, SELinux’s Type Enforcement (TE) and Capsicum have common intellectual roots in microkernel capability systems. TE began life as a set of mandatory controls for language/microkernel capabilities, allowing limits to be placed on the spread and use of capabilities. Only later did its migrate its way to UNIX — you can still see terminology references to these origins in the form of the ‘Security Server’, which was a userspace task in systems like DTMach, and the ‘Access Vector Cache’, which still serves a performance function, but was even more critical when policy originated in userspace but enforcement occurred locally in kernel or in other user processes. Today SELinux controls access to high-level UNIX kernel objects such as files, sockets, etc, rather than low-level IPC objects and user-defined objects served over them.
Capsicum likewise blends ideas about capability systems with UNIX, having capabilities represent high-level UNX kernel objects (files, sockets, etc). We argue in the Capsicum paper that approaches like MLS/TE and Capsicum are complementary: Capsicum is about letting programs express their own compartmentalisation in terms of application-defined structures, whereas MAC schemes control overall system behaviour (with varying degrees of granularity) but in a far more static way. For example, while you can implement Power Boxes (user-driven granting of rights to processes based on UI actions — eg., an Open File dialog allows a user process to access the file) using MAC, capabilities are a much more suitable structure. On the other hand, information flow control and global policies on the interactions of different applications may be better done using a labelling scheme. Of course, capability systems aren’t limited to intra-process control, and one open question is whether, as Capsicum sees more deployment, it gets used beyond simple application compartmentalisation. If you look at contemporary desktop systems such as Mac OS X, KDE, etc, they all take on message-passing object-oriented structures that lend themselves to capability-like design, and might be a good match.
To P. Fudd: Trusted Solaris was insanely hard to set up, too, so it’s a problem with combinatorial explosion in the requirements, not SE Linux itself. N categories times 5 levels times the *-property makes my ears bleed!
Stronger implementation and weaker feature-sets are, IMHO, part of a defence in depth against confidentiality leaking out.
I’ve always taken the view that the complexity of SELinux policies reflects the complexity of the software it describes — TE policies provide a natural centralised way to describe things, but the things they try to describe are unnatural and very uncentralised. Capability-oriented approaches provide different things and do them in different ways — but one merit to them is that they keep policy close to the code that it has to describe, which offers maintenance benefits. TE as applied to fixed-function guards (one of its original target environments) presumably works a lot better than rapidly moving desktop environments with extremely diverse and dynamic applications.