Messages in this thread | | | Date | Wed, 26 Sep 2007 17:01:36 +0200 | From | Miloslav Semler <> | Subject | Re: Chroot bug |
| |
> > This is basically both painfully racy and easily broken with umount > and/or access to proc. See this busybox-compatible example: > > ## Set up chroot > mkdir /root1 > mount -o mode=0750 -t tmpfs tmpfs /root1 > cp -a /bin/busybox /root1/busybox > > ## Enter chroot > chroot /root1 /busybox > > ## Mount proc > /busybox mkdir /proc > /busybox mount -t proc proc /proc > > ## Poke around root filesystem (this may be all you need) > /busybox ls /proc/1/root/ > > ## Detach our chroot so we're no longer a sub-directory > /busybox umount -l /proc/1/root/root1 > > ## Now we can easily chroot to the original root, since it isn't in > our ".." path > exec /busybox chroot /proc/1/root /bin/sh > > > See how easy that is? Unless you stick the above parent-directory > check (which is still racy against directories being moved around) for > *EVERY* directory component of *EVERY* open/chdir-ish syscall, you are > still going to be easily worked around through many different methods. > so there is no discussion about mount & others. I think, if you have CAP_SYS_MOUNT/CAP_SYS_ADMIN, you need not solve chroot() and how to break it. - 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/
| |