Re: Chroot bug
From: Serge E. Hallyn
Date: Tue Sep 25 2007 - 12:53:58 EST
Quoting Miloslav Semler (majkls@xxxxxxxxxxx):
>>>> So what? Just do this: chdir into the root after chroot.
>>> I don't think so. His exploit just got me all the way out of a chroot
>>> within a
>>> chroot within a chroot, inclusive of lots of chdirs.
>> Close all fds that point to directories outside the root ;-)
> This does not help. Let's try:
> chroot somewhere
> mkdir foo
> fd = open /
> chroot foo
> fchdir fd
> chdir ".."
> chdir ".."
> chroot "."
> so you are in root.
Yes, to understand why that doesn't work it helps to understand why
pivot_root *does* work. Pivot_root takes the new_root, which must be
a mount, and detaches it from it's mountpoint. So it's not that we
try to intercept a chdir(root_dir/..), but rather we remove root_dir
from it's parent dir so that root_dir/.. must always return root_dir.
I'm sorry but I really don't see where hacking chroot to try and
detect and prevent chroot escapes is going to be acceptable to
anyone so long as pivot_root does the trick anyway. If you want
portable, then write a little linux-only safe_chroot() library call
which does unshare();pivot_root() on linux and just chroot on a
system that does try to stop chroot escapes.
Besides as others have alluded to, if you have root privs, you can
always mknod /dev/hda1, mount that under /mnt, and then chroot or
pivot_root to there.
The containers work will, in fact, be intended to be a *safe*
jail. That'll happen through pivot_root, capability masking,
perhaps device namespaces, etc. But a secure container is still
a ways off.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/