Re: RFS: Plash: a shell and restricted environment for running programs with minimum authority
Steve Langasek <vorlon@debian.org> wrote:
> > > On Sat, Aug 20, 2005 at 03:01:40PM +0100, Mark Seaborn wrote:
> > > > I'm looking for a sponsor for putting Plash into Debian.
>
> > > > The main page is: http://plash.beasts.org
> > > > and Debian packages are at:
> > > > http://www.cs.jhu.edu/~seaborn/plash/plash_1.11_i386.deb
> > > > http://savannah.nongnu.org/download/plash/plash_1.11.dsc
> > > > http://savannah.nongnu.org/download/plash/plash_1.11.tar.gz
> > > > (The Debian source package contains a copy of glibc 2.3.3, which is
> > > > 13Mb, but the source for Plash itself is only 200k.)
> *Why* does it need the glibc source to build? Does it need *all* of the
> source, or is there some way to get its size down to a sane level?
It builds a modified version of glibc, so yes, it needs all the source.
> Why does it use a modified version of glibc, instead of intercepting
> library calls using an LD_PRELOADed wrapper?
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.
More importantly, Plash needs to intercept these calls when they're
made by the dynamic linker. Plash's chroot() environment doesn't
contain any executables or libraries (except the dynamic linker), so
the linker needs to be able to receive file descriptors for these via
a socket.
> Is this because a user could unset the LD_PRELOAD variable to escape
> the environment? If that's the case, what happens if a user copies
> their own libc.so.6 into the chroot and tells the dynamic linker to
> use *that*?
Plash doesn't rely on a program being linked with its version of glibc
to provide security. That would provide no security at all, because a
process can easily make syscalls itself. Plash uses chroot() to stop
a process from accessing files using the usual Linux syscalls. If the
process decides to use a normal libc, it will just see a couple of
files in the filesystem ("/special/ld-linux.so.2" and an inaccessible
lock directory).
There are other restricted environments, such as systrace, which
modify the kernel in order to work. Since Plash modifies libc
instead, it means you don't have to recompile the kernel, reboot, or
worry about a kernel patch that could affect your whole system. libc
is also much less of a moving target than the kernel. Building a
patched kernel requires the kernel source, just as building a patched
libc requires the libc source. But if you use a patched libc there's
much less need to build it from source yourself than with a patched
kernel, because there's much less variation in libc.
I think this trade-off is quite favourable for everyone, except
perhaps the distribution, which has to host the libc source. This is
reversed for the kernel, because distributions leave recompiling to
the user.
> Including a full copy of glibc in this package also means that it
> will be affected by the same security holes that affect the main
> glibc package, and you say that it doesn't even use the same base
> version of glibc. I don't think the security team will go for this.
This is true. I need to investigate what patches Debian applies to
glibc (and possibly why they're not in upstream glibc).
However, the fact that programs are usually run with a lot more
authority than they actually need is a significantly bigger security
problem than those problems that Debian's patches to glibc are likely
to address. A program is always likely to have bugs, so it makes
sense to limit the damage that those bugs can do by limiting the
program's authority. Plash addresses this more fundamental problem so
I would argue that it has value even without the Debian glibc patches.
Mark
Reply to: