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