On Sun, Dec 03, 2000 at 12:45:29AM -0800, Thomas Bushnell, BSG wrote: > > I still don't understand your example; I found it very unclear, so I > might be operating under a misunderstanding. im going on memory and im not terribly familier with all the syscalls, but the basic jist is doing an fchdir() to a directory under the current chroot, so if you can chroot down one more level then fchdir back up you have effectively broken the chroot(). i wish i could remember where i read about this.... say your chrooted to /chroot you see in your chroot jail: /foo/bar/ (both directories) you open a file descriptor on /foo you then chroot to /foo/bar, now foo is no longer visable. you fchdir() to foo, now your out of the chroot entirely. > > a completely seperate issue is whether its possible to make a setuid > > root program to allow users to chroot safely. i am only arguing that > > changing the kernel to allow any user to use chroot() would end up > > making chroot() useless for security purposes. > > I don't think this is true at all. Suppose a good careful program > chroots a user into a special environment. It's a good, careful > program: it leaves no extra file descriptors hanging around, and it > has designed the chrooted playground carefully. How can such a user > escape from the environment if we let them chroot? were talking about two different things, i am talking about allowing any user to use the chroot() system call, so they could write any program they want calling chroot() and have it work instead of getting -EPERM back from the kernel. your talking about (i think) rewriting /usr/bin/chroot so it could be safely suid root doing all the necessary checks to make sure the user is not playing any games with file descriptors. besides that i think we are in agreement that deprivved chroot() system call would be a failure anyway since there is the su trick you posted earlier. even if we were to write a safe setuid root chroot program it would still have to do a LOT of checking to ensure no games are being played, such as fake chroot/etc/passwd and /bin/su hard links... -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpSQBcM_B7du.pgp
Description: PGP signature