David Newall <[EMAIL PROTECTED]> wrote: >> Normal users cannot use chroot() themselves so they can't use chroot to >> get back out > > I think Bill is right, that this is to fix a method that non-root > processes can use to escape their chroot. The exploit, which is > documented in chroot(2)*, is to chdir("..") your way out. Who'd have > thought it? Only root can do that, but even that seems wrong. Chroot > should be chroot and that should be the end of it.
chroot with having open directories outside the chroot is a convenience feature, allowing e.g. to install programs into a different root while opening the archives from another root tree. Only if there is a working capability system preventing root from accessing the hardware*, a chroot may become a security feature. Off cause having the new fchdir, you might run "chroot /var/foo 3< /" in order to pass a dir filehandle and compromise your own security, but this is nothin a system should protect against. The only problem I'm concerned about is passing a file descriptor to a privileged, compromised process using an abstract unix socket. This combines two different privileges, possibly increasing the impact of the attack. I think it may be enough to not allow passing directory fds if the two processes have different device/inode/namespace, but I'm not sure about device fds. *) chmod u+s binary; su nobody; exec binary; mount tmpfs /; mknod dev_mem should be enough to void most root-in-chroot setups. Very untested. -- Funny quotes: 26. If you take an Oriental person and spin him around several times, does he become disoriented? Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/