Re: Capsicum: practical capabilities for UNIX

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

(Everything is my personal opinion in this mail).

On 24.09.2010 21:46, David Young wrote:
> A couple of weeks ago I read a paper on Capsicum, a
> "lightweight OS capability and sandbox framework,"
> <http://www.cl.cam.ac.uk/research/security/capsicum/>.  Capsicum looks
> like a giant step in the right direction for UNIX security research.
> I'd like to see a similar function in NetBSD.  What are others'
> impressions of Capcisum?

It is the "capability-based" model that seems to gain momentum by trying
to compartmentalize processes. Somekind of privilege separation model
next gen, like jails/containers for chroot.

For me, it is the counterpart of administrator-defined security,
oriented towards development ("developer-defined security"?).

>  Is anybody working on a port?

For NetBSD? I don't think so. Note that Chromium will require it, IIRC.

> I have a couple of concerns about Capsicum at its current level of
> development.  First, I'm wary of "self-compartmentalization" of
> programs and libraries.  It seems like it could be a lot of work to add
> self-compartmentalization to just the programs in NetBSD's base system,
> and when it was finished, I doubt that so many changes would be both
> trustworthy and consistent.

It always depends on the way you implement it. That can be helpful when
you want to isolate web page rendering in a subprocess that can only use
a narrow set of syscalls, or protect string parsing for a
tcpdump/wireshark by just having a process with very limited
possibilities regarding syscalls (like read/write on a specific file
descriptor).

Current models I have seen use a combination of setuid() and chroot()
for isolation, and they have to be root somewhere in the loop to benefit
from these calls. I am not talking about MAC/RBAC stuff that are
addressing other security issues (administrator-defined security vs
developer-defined security), or jails/vserver/Xen, which are more
"complete-OS compartiments."

If you want to see what a capability model looks like for an OS, I would
recommend a quick look at Kauer's thesis for L4.sec [1].

>  The second concern is related to the first:
> a Capsicum sandbox doesn't simulate access to the global namespace for
> the purpose of unmodified programs calling, e.g., open(2)---can it?  The
> authors of the Capsicum paper are already thinking about the question
> (see section 4.3, "gzip"); I'm eager to see what they come up with.

IMHO, that's the biggest concern. And I can't see how they could come up
with a solution other than "rewrite/refactor whole programs."

> For consistency, user confidence and convenience, I'd like to see a
> wrapper program or shell built-in, "capsicum [capabilities] [program
> [arguments ...]]", that creates a sandbox, grants it the mentioned
> <capabilities>, and starts in it the given <program> with the given
> <arguments>.  Maybe that wouldn't be hard to do.  Maybe there's a better
> way, too.  Your thoughts?

I, for one, welcome our new systrace overlords.

oops :)

IMHO, one difficult thing to get right are multi-process/multi-threaded
programs (systrace...), among other things. While gzip applies easily to
this model, this may get trickier when one would want to apply such
things to a complete OS, without breaking too much stuff in the process
(devil lies in the details).

More problematic: each mainstream OS has now its own "OS compartiment
model". Solaris has zones, FreeBSD has jails, Linux distros have dozens
(containers now?), and so on. I just hope that we do not end up with a
capability API different for each OS: that would hamper portability, and
restrain most third party developers from using it.

Note that Capsicum is different from the "POSIX" capabilities, which are
more or less "separate root privileges in smaller sets."

My 2 cents (:

[1] http://os.inf.tu-dresden.de/papers_ps/kauer-diplom.pdf

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost