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 <[email protected]> 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 [email protected] Urbana, IL * (217) 278-3933
