Re: RFS: Plash: a shell and restricted environment for running programs with minimum authority
Joey Hess <joeyh@debian.org> wrote:
> Mark Seaborn wrote:
> > LD_PRELOAD isn't good enough. Plash needs to replace *all* uses of
> > system calls that use filenames, including glibc's internal uses of
> > those system calls. Back in the day of glibc 2.2.5, you *could* do
> > this by overriding "__open" and "__libc_open" as well as "open". But
> > with glibc 2.3.3, a lot of these calls are now resolved internally,
> > without going through the dynamic linker (glibc uses "__GI_open"
> > etc.). Furthermore, glibc inlines system calls, including "open", in
> > some places.
>
> Yeah, I know from mooix (which uses a similar but less generalised
> security model as plash), that wrapping open() is horrendous.
>
> I suppose that syscall interception was considered and not used for some
> reason?
I didn't do system call interception mainly because it involves
modifying the kernel. You can think of Plash's libc approach as
"build once, run anywhere [well, any Linux]". It's just that the
build step is a bit of a hassle.
Linux's ptrace mechanism is no good because it's not secure across
fork(). It's also slow, and there's no way to be selective about
which syscalls you intercept.
The simplest syscall interception mechanism I've seen is that used by
Ostia. It has a kernel module for Linux that will bounce selected
syscalls back into user space, to the process that made the syscall.
A library then handles the call by making a request to a server across
a socket -- very similar to Plash in this respect. Unfortunately, the
authors aren't releasing the code for their module. I don't know
enough about Linux internals to write my own version while having
enough confidence that I won't break something else.
> I'd be interested in sponsoring plash, but this libc issue needs to be
> resolved in some way first.
That's great that you're interested in sponsoring it.
I've looked into this a bit more. Debian's glibc package produces
libc6-pic, a binary package which contains the file libc_pic.a that
glibc produces as an intermediate result. This is used by
boot-floppies to build a cut-down glibc. Plash could use it to build
its glibc.
For this to work, glibc will need to be patched so as not to inline
syscalls such as open(). This inlining isn't done much so it
shouldn't be a big deal. Also, libc6-pic will have to include the
object code for the dynamic linker and for libpthread.
I see now that the approach to sharing data between source packages is
to copy the data into a regular package, even if this package is just
used by one or two source packages.
This should resolve the libc issue. What do you think? I'll have a
go at getting Plash to build this way and talk to the Debian glibc
maintainers about these changes.
Mark
Reply to: