Subject: Re: chroot: why super-user only?
To: David Young <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 01/23/2003 15:02:26
On Thu, 23 Jan 2003, David Young wrote:
[DY: Does chroot(2) require super-user privileges so that you cannot fool a
[DY: setuid program such as passwd into reading or writing a different file
[DY: than /etc/passwd ? Is there any other reason?
This is precisely why chroot(2) is disallowed to a mortal, only more so.
normal user a creates, say, a hierarchy under a mysteriously
writable directory under the root filesystem, creating a hard link from
/usr/bin/su to, say, /bogusdir/usr/bin/su.
said user manages to write his own copy of /etc/master.passwd
with, say, root's encrypted passwd string removed.
said user makes an exec wrapper:
...compiles it and puts it in as /bogusdir/bin/hole.
chroot is not restricted. User chroots into /bogusdir, runs
/usr/bin/su. Bingo. No password. He is now root.
User makes /bin/hole mode 4555, owner root.
User exits from root shell.
User exits from chrooted environment.
Guess what lives at /bogusdir/bin/hole now?
[DY: Put another way, under what conditions is it safe for a non-root user
[DY: to chroot(2)?
This falls into the same category of "Under what conditions is it safe to
point a loaded gun at oneself?", really.
You would need to disallow set-id execution (and, arguably, device
access.) The effects of this are left as an exercise for the
Hack on NetBSD, and your code runs on over 40 architectures.