David Newall <david@davidnewall.com> wrote:

quoted text
>> 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: hrzoi8.sT@gYjoOs.7eggert.dyndns.org zq@u1kq.7eggert.dyndns.org
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/