From: Nick Craig-Wood (ncw_at_axis.demon.co.uk)
Date: Thu 24 Jan 2002 - 09:59:21 GMT
On Thu, Jan 24, 2002 at 12:34:45AM -0500, Jacques Gelinas wrote:
> On Wed, 23 Jan 2002 22:07:25 -0500, Martin Josefsson wrote
> I am posting this message since it may be of interest. At the end
> you will find one idea I have to plug the chroot flaw.
> > I've been playing with vserver a little here and started thinking about
> > chroot's and ended up trying to write code to break out of them.
> > This code can break out of an chroot in Linux kernel
> > 2.4.18-pre3-ac2:
This surely must be a kernel bug?
> > chroot("/tmp");
> > chdir("/");
At this point the program has no references to anything above /tmp
# ls -l /proc/2763
lrwxrwxrwx 1 root root 0 Jan 24 09:11 cwd -> /tmp
lrwxrwxrwx 1 root root 0 Jan 24 09:11 root -> /tmp
> > mkdir("blabber", 0755);
> > chroot("blabber");
And neither does it here
# ls -l /proc/3198
lrwxrwxrwx 1 root root 0 Jan 24 09:31 cwd -> /tmp
lrwxrwxrwx 1 root root 0 Jan 24 09:31 root -> /tmp/blabber
> > chdir("../bin");
So why on earth should this work? I can see why it does! Surely that
is the bug we should be working on? I expect there is some
implication in speed terms in checking cwd vs root, but it need only
happen if root != "/" && root != cwd surely which won't slow the rest
of the kernel down.
> Someone told me the forcing the chdir right in the chroot system call
> was breaking posix compatibility and it was bad. There is apparently
> a big thread on linux kernel mailing list about this. I have not seen it
> but I was told that the end argument was that fixing chroot was a big
> can of worm...
Here is part of a recent thread...
And a comment from Alan Cox who is saying that you can't allow chroot
in a chroot if you want to be secure.
-- Nick Craig-Wood ncw_at_axis.demon.co.uk