On 10/05/2013 06:17:55 PM, Linus Torvalds wrote:
On Sat, Oct 5, 2013 at 4:07 PM, Rob Landley <rob@xxxxxxxxxxx> wrote:
>
> A todo item I've had _forever_ is fixing chroot() to not be broken
so that
> you can trivially break out of a chroot via:
What drugs are you on?
Enough caffeine to count as a plural.
Your example is moronic, and against all _documented_ uses of chroot.
Yes. That's why it's an exploit.
My example allows someone who can chroot again to break out of a
previous chroot, which is the reason that lxc doesn't use chroot.
> chdir("/");
> mkdir("sub");
> chroot("sub");
> chdir("./../../../../../../../..");
After you do a chroot(), you need to chdir *into* the root. The reason
chroot() itself doesn't do that is simple: you may still be doing
various setup stuff.
Yes, I asked you about this years ago before I implemented chroot and
switch_root for busybox and toybox, I know how to use it _right_. What
I'm saying is it doesn't prevent something running in the chroot from
doing it _wrong_, which is why lxc can't use chroot to implement
containers and instead uses pivot_root, which is a HORRIBLE system call
I'd like to move away from.
I want to implement a lightweight container command for toybox, but
when I dug into lxc and tried to swap their pivot_root for a simple
chroot, I got corrected.
But your example is just stupid. Yes, chroot'ed environments can
generally be escaped, but your example escape is simply because you
didn't use chroot() correctly.
The above is code you run _in_ the chroot. After the first user used
chroot incorrectly.
The problem is that there's only one "/" symlink. If you move it down
under your current "." then nothing stops you from following .. all the
way up the tree. The fact you can do this after the fact, from within
an existing chroot, is the problem.
So learn this pattern: every time you use chroot, add a simple
chdir("/");
immediately after the chroot call.
I do. But I can't stop other people from NOT doing that afterwards.
Rob--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
