Capsicum -- 9.x merge in sight

Robert Watson rwatson at FreeBSD.org
Sun Jan 23 15:56:14 UTC 2011


On Sun, 23 Jan 2011, Ivan Voras wrote:

>> As many of you will now have heard, the Computer Laboratory at the 
>> University of Cambridge and Google have been collaborating for the last few 
>> years on a security research project called Capsicum. It consists of a set 
>> of extensions to the POSIX API adding a new "capability mode", 
>> "capabilities", "process descriptors", and several other additions required 
>> to implement a capability-oriented sandbox model in UNIX. These
>
> Hello,
>
> How is Capsicum positioned, from user & admin perspective, when compared to 
> the MAC work on FreeBSD and SELinux on Linux? Is one the superset of 
> another, will one obsolete another?

This is a point addressed in some detail in the paper, which considers the 
relationship between Capsicum and other security models.  Capsicum is really 
addressed at the application author, whereas MAC models are typically 
addressed at a blend of system integrators and system administrators.  As a 
result, users mostly benefit from Capcisum transparently.  We argue that 
Capsicum complements other security techniques, such as MAC, DAC, etc, which 
serve different roles in system design.  As a result, Capsicum should be 
entirely transparent to end users -- except that vulnerabilities in 
applications become less critical -- which is quite different from what you 
see in various MAC models, including the TE model shipped with SELinux.

>> The current plan is *not* to merge libcapsicum, a userspace library used by 
>> certain applications to construct sandboxes, as we feel the API remains 
>> insufficiently mature at this point.
>
> I vaguely remember that the MAC work has never gotten as popular on FreeBSD 
> as SELinux on Linux because it lacked user-oriented tools and documentation 
> - is there a danger Capsicum will end up the same?

There's a long philosophical discussion to have on this topic, but suffice to 
say that the success or failure of Capsicum will depend on its adoption by 
application writers.  The starting point for applications is our own 
application suite: the tools, daemons, etc, in our own operating system, and 
it seems we have a lot of interest in our community in taking that task up. 
In as much as we can convince other OS authors that Capsicum is a good idea, 
and that they should adopt it, that will help a great deal.  Discussions in 
the Chromium, NetBSD, etc, communities are promising in this sense, but a lot 
more has to be done.

One of the hardest problems in this area is one that Capsicum makes 
accessible, but doesn't solve: how to improve programmability for 
compartmentalisation and privielge separation.  Today, that programmability 
problem is significant, but there are also quite a few interested parties 
working on it, and also existing components that use compartmentalisation -- 
Chromium being one of them, and hence a good case study since it allows us to 
compare different models from a programmer perspective.  If you haven't yet 
read the paper, please do so, as I think it will help answer some of these 
questions.

You may remember, BTW, that while I was at NAI Labs, we had a project to port 
the SELinux FLASK/TE parts to FreeBSD, and for a period, shipped an "sebsd.ko" 
kernel module implementing it using FreeBSD's MAC Framework.  We saw very 
little interest from the community, and part of the reason for that is that 
it's actually extremely difficult to use outside of narrow appliance-like 
environments (for which TE was originally designed).  It turns out that TE is 
used with FreeBSD, however: McAfee's Sidewinder firewall (the origins of the 
TE implementation in SELinux began life at SCC, who were bought by McAfee a 
couple of years ago), and also the Kylin operating system, which actually does 
use our SEBSD work.  If there's interest in updating SEBSD, the pieces are all 
in Perforce, and over the years, the MAC Framework has evolved in several ways 
that would make that easier.  However, even in the Linux community, SELinux is 
considered fairly controversial and quite difficult to use.

And, to be far, MAC is actually extensively used by FreeBSD consumers. 
You'll find the MAC Framework in use to host policies in many downstream 
products: Mac OS X, iPhoneOS (now iOS), Junos, McAfee's Sidewinder, nCircle's 
products, and so on.  The thing that has made MAC most hard to deploy (and why 
Apple has found it easier to deploy) actually has to do with the weakness of 
semantics of path names in UNIX -- something that's a bit different in Mac OS 
X.  That same weakness has made SELinux hard to deploy: you can't efficiently, 
effectively, and safely use path names for implicit security labelling, 
meaning that you end up having to manage security labels on objects. 
(There's some interesting literature on this, see DTE vs. TE).  This same 
concern has hurt the effectiveness of auditing as well.  But it's hard to fix: 
many UNIX file system concepts (hard links, flexible mounting model, files 
without names, etc) are embedded in the structures of critical applications.

Robert


More information about the freebsd-arch mailing list