Re: Capsicum: practical capabilities for UNIX

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Tue Oct 26 2010 at 13:04:30 +0200, Jean-Yves Migeon wrote:
> 
> On Mon, 25 Oct 2010 20:13:16 -0500, David Young <dyoung%pobox.com@localhost> 
> wrote:
> > 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):
> > 
> > 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;
> > }
> 
> That would only work with dynamic executables. Sandboxing static
> executables that way will not work.

Less obviously and more dangerously it will not work for syscalls done
from libc (cf. rpc code in rump nfsd).  Maybe it's possible to link
libc.so so that the linker doesn't resolve unresolved symbols at that
stage, but I haven't investigated that path.

[i didn't read this thread, at least not yet, so apologies if that was
mentioned earlier]