Re: RFC: New security model secmodel_securechroot(9)

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sun, Jul 10, 2011 at 03:50:07PM +0200, Jean-Yves Migeon wrote:
> On 09.07.2011 20:08, Thor Lancelot Simon wrote:
> > However, I'd like to see a different system call used to enter the chroot
> > in this case, so that it's possible to have a normal, less-restricted
> > chroot at the same time.
> 
> IMHO that will defeat its purpose: programs will have to get patched to
> call some sort of securechroot(2). Everything outside of base (or
> patched pkg) won't benefit from it.

I don't think changing the semantics of chroot(2) in this rather
grab-bag way will be appropriate for as many existing chroot-using
programs as you expect.  It's remarkably hard to get the set of permissions
just right.

The reason I don't think that is that I tried it.  Almost exactly what
has been done here.  I ended up first having to back down and use a
different system call to enter the modified-chroot (and a small "runner"
program to invoke the chrooted executables) and next having to write a
somewhat more robust security model.

For example, the IKE daemon chroots -- but one would think (at least I
did!) that these untrusted, chrooted programs should not be able to
suck key material out of the kernel.

If you just ban all interface ioctls, then you can't make rootly programs
like rtsol chroot.  Very frustrating.

Ultimately I would argue that if you're trying to prevent persistent
compromise, this approach is a good one, but the set of actions prohibited
must be restricted to only those that write persistent data -- things like
the interface ioctls have to be left alone.

Then, it might be reasonable to apply these restrictions to anything
chrooted.

But if you're trying to do that _plus more_ (turn off some other "root"
actions for chrooted programs to make them "less rootly") then you need
to be able to fine tune the set of permitted/prohibited actions per
program, or else lots of stuff you want to run in a chroot, it will turn
out that you can't.  That means using a different system call to enter
the chroot, finding another way to mark the executable, or something
like it.

What I ended up with on my system that started out pretty much where
this proposal does was with a hack that used special group IDs as
pseudo-capabilities.  Not ideal, but I did try the "just turn off
everything that looks 'dangerous' when youc all chroot(2)" approach
and found that it did not work nearly as smoothly as I hoped, mostly
because it prevented me from chrooting all kinds of things I wanted
to.

Thor