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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1323363493.10724.58.camel@lenny>
Date:	Thu, 08 Dec 2011 11:58:13 -0500
From:	Colin Walters <walters@...bum.org>
To:	Andy Lutomirski <luto@....EDU>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Daniel Walsh <dwalsh@...hat.com>,
	Stephen Smalley <sds@...ho.nsa.gov>, kzak <kzak@...hat.com>
Subject: Re: chroot(2) and bind mounts as non-root

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).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/