Re: Capsicum: practical capabilities for UNIX

[David Young <dyoung%pobox.com@localhost>]

On Tue, Oct 26, 2010 at 02:33:40PM +0300, Antti Kantee wrote:
> 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.

Yeah, it's definitely not obvious.  The open(2) calls *will* fail,
though.  The application behavior may be dangerous, but it's not
dangerous behavior outside of the sandbox.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933