Re: Capsicum for Linux?

On 8 Jan 2014, at 22:30, Mark S. Miller <[email protected]> wrote:

> On Wed, Jan 8, 2014 at 1:04 PM, Nigel Williams <[email protected]> wrote:
> Via the popular news channels, Google has sponsored a port of Capsicum
> to Linux, details here:
> 
> https://github.com/google/capsicum-Linux
> 
> http://www.lightbluetouchpaper.org/2013/12/20/2013-capsicum-year-in-review/
> http://www.cl.cam.ac.uk/research/security/capsicum/linux.html
> https://lists.cam.ac.uk/pipermail/cl-capsicum-discuss/2013-October/msg00004.html
> 
> What do cap-talkers think of capsicum generally? lipstick-on-a-pig or
> butterfly from a chrysalis?
> 
> My view: Important progress towards real-world-deployable ocaps. The legacy pressure problem has always been our worst, and this is one of the most promising angles at overcoming it. As an ocap system, it has some weaknesses, but all of these seem repairable. I'm a fan.


The perspective we've taken thus far in Capsicum is that, although the UNIX kernel is a huge TCB, real-world applications are even bigger ones, and just as important for end users. While I see compartmentalisation of OS kernels vs. applications as being very similar intellectual problem spaces, there is much more traction to be had on applications -- and, applications contain more lines of code, risky behaviours, and these days, critical security functions.

To follow up on a discussion we had in Cambridge, BTW, I tend to see Capsicum as a 'capability system' when it comes to kernel objects, rather than an 'object-capability system'. It is true that Capsicum capabilities refer to objects, but when fast-pathing kernel-object access (eg., files, directories, sockets, devices, etc), there isn't a general-purpose invocation mechanism that supports arbitrary wrapping/interposition. Userspace objects in Capsicum, in contrast, are actual object capabilities, as they are built on a general-purpose invocation system grounded in message passing.

This may be a stronger definition of object capability than others prefer, but I think captures a key point about linking capabilities with object orientation: if you don't have arbitrary subclassing or similar functions, there are a range of useful controls that are difficult/impossible to impose, which I think is true of certain Capsicum object types. For example, files may be referenced by capabilities, but in UNIX don't support arbitrary interposition on memory mapping -- in contrast to microkernel-based schemes in which userspace pagers allow interposition on memory-mapped I/O to provide more granular control (although this also has semantic issues with coherency...).

Robert

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk