Re: Capsicum: practical capabilities for UNIX

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Mon, Oct 25, 2010 at 08:13:16PM -0500, David Young wrote:
> On Fri, Sep 24, 2010 at 02:46:10PM -0500, 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?  Is anybody working on a port?
> > 
> > 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.  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.
> > 
> > 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've been wondering if the dynamic linker could simulate access to
> the global namespace by supplying alternate system-call stubs.  Say
> rtld-elf-cap supplies its own open(2) stub, for example, that searches
> Capsicum's fdlist for a suitable file descriptor on which to call
> openat(2):

I like to keep one thing to be done in the single place.  Namespace
loolup is done in namei(9) now.  We already have chroot and emul
root hac^Wfunctions.  Extending them seems more natural to me.

How they work is basically to keep a pointer to root in proc::p_cwdi
(struct cwdinfo).  When a proc changes its root, sys_chroot()
changes proc::p_cwdi::cwdi_rdir (struct vnode *).  I can't see how
this differs what you want to achieve?

(I wonder a possible first step is to decouple namei lookup code
and VFS.)

Masao

> 
> int
> open(const char *path, int flags, mode_t mode)
> {
>       const char *name;
>       int fd;
> 
>       for (name, fd in fdlist) {
>               if (path is-under-directory name)
>                       return openat(fd, path, flags, mode);
>       }
>       errno = ENOENT;
>       return -1;
> }
> 
> Dave
> 
> -- 
> David Young             OJC Technologies
> dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635