Re: Capsicum: practical capabilities for UNIX

["Perry E. Metzger" <perry%piermont.com@localhost>]

On Sat, 25 Sep 2010 13:36:18 +0200 Jean-Yves Migeon
<jeanyves.migeon%free.fr@localhost> wrote:
> >  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."

Actually, it is pretty easy for most systems programs to retrofit what
you want. It is a lot harder for arbitrary programs, but that's
another story.

> I, for one, welcome our new systrace overlords.
> 
> oops :)

Systrace is a MAC-like system. It is NOT a capability architecture.

> IMHO, one difficult thing to get right are
> multi-process/multi-threaded programs (systrace...),

systrace's implementation made it hard to deal with multithreading,
but the MAC concept has no such trouble.

Capabilities and multiple threads are not an issue at all, indeed,
many past capability systems are inherently multithreaded.

> More problematic: each mainstream OS has now its own "OS
> compartiment model".

This isn't per se a compartment 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.

Another reason, I think, for adopting Capsicum rather than reinventing
the wheel. I think it is a set of good ideas.

Perry
-- 
Perry E. Metzger                perry%piermont.com@localhost