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]

Date:	Thu, 15 Dec 2011 10:55:50 -0800
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Colin Walters <walters@...bum.org>,
	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

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

morgan> sudo su luser
luser> mkdir /tmp/chroot/
luser> chmod go-rx /tmp/chroot/
luser> exit

morgan> cat > launcher.c <<EOT
#include <stdio.h>
#include <unistd.h>
int main(int argc, char **argv)
{
  int ret = chroot("/tmp/chroot");
  printf("chroot %s.\n", ret ? "failed" : "worked");
  ret = chdir("/");
  printf("chdir %s.\n", ret ? "failed" : "worked");
  // Insert exec code to invoke chroot'd shell or whatever.
  return ret;
}
EOT
morgan> make launcher
cc launcher.c -o launcher
morgan> mv launcher /tmp/
morgan> sudo -s
root> setcap cap_sys_chroot=ep /tmp/launcher
root> cp <files and directories needed in the chroot> /tmp/chroot/
root> su luser

luser> /tmp/launcher

The last line being something that involves luser only - ie. it gives
no user privilege away to any child it might launch. Its also the only
regular user able to chroot to this luser owned chroot (because that
directory is exclusive to that user).

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

Thanks

Andrew

On Wed, Dec 7, 2011 at 12:54 PM, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> On Wed, 07 Dec 2011 12:34:28 -0800
> "H. Peter Anvin" <hpa@...or.com> wrote:
>
>> On 12/07/2011 09:54 AM, Colin Walters wrote:
>> >
>> > The historical reason one can't call chroot(2) as non-root is because of
>> > setuid binaries (hard link a setuid binary into chroot of your choice
>> > with trojaned libc.so).
>>
>> No.  The historical reason is that it lets anyone escape a chroot jail:
>
> Beg to differ
>
> Nobody ever considered chroot a jail except a certain brand of
> urban-legend-programming people. Indeed chroot has never been a jail
> except in the 'open prison' security sense of it.
>
> The big problem with chroot was abusing setuid binaries - particularly
> things like uucp and /bin/mail.
>
>
--
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/