Re: chroot(2) and bind mounts as non-root

[Colin Walters <walters@verbum.org>]

On Wed, 2011-12-07 at 11:40 -0800, Andy Lutomirski wrote:

> I will personally always be nervous until something like this happens:
> 
> http://thread.gmane.org/gmane.linux.kernel.lsm/10659
> 
> execve() is IMO scary.

Yeah, this came up in the context of the seccomp filter stuff too.  

So...it's worth noting that as far as SELinux goes, the beautiful thing
is that setuid only changes uid - it doesn't (by default) change the
domain.  So in this case for example, if the calling domain doesn't
have:

  self:capable { setpcap sys_chroot }

The binary is just going to error out.  Very few domains in the
reference policy have either of those, and only one non-unconfined
domain has both - seunshare.  (At least via grep, I didn't try an
analysis tool).

Oh crap, speaking of seunshare:
https://bugzilla.redhat.com/show_bug.cgi?id=633544

They should clearly be using SECBIT_NOROOT too - that would have avoided
the original hole.

In fact, I now notice my program is a safer generalization of seunshare.
I've added dwalsh to CC.

As far as other LSMs go - honestly I'm in the camp that they're stupid,
and SELinux is the only sane one.  That and opt-in application controls
such as seccomp are where we should be headed.

So instead of your execve_nosecurity, why don't we make SECBIT_NOROOT
disable domain transitions too?  (And encourage the other LSMs to treat
it similarly).

Here's some further food for thought - what if we made certain system
calls that were previously privileged suddenly start working if the
process is SECBIT_NOROOT | SECBIT_NOROOT_LOCKED?  I'm specifically
thinking of unshare(2) and chroot(2).  The tricky part is more allowing
a subset of mount system calls (I need to be able to mount procfs, but
clearly we don't want the user to be able to mount real devices).