From: Al Viro <viro@ftp.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: sys_chroot+sys_fchdir Fix
Date: Wed, 26 Sep 2007 00:25:08 UTC
Message-ID: <fa.0EU7UYTd8aGBHwfmF7uRimRU3NA@ifi.uio.no>

On Tue, Sep 25, 2007 at 04:53:00PM -0400, Phillip Susi wrote:
> Alan Cox wrote:
> >On Fri, 21 Sep 2007 13:39:34 -0400
> >Phillip Susi <psusi@cfl.rr.com> wrote:
> >
> >>David Newall wrote:
> >>>* In particular, the superuser can escape from a "chroot jail" by doing
> >>> "mkdir foo; chroot foo; cd ..".
> >>No, he can not.
> >
> >The superuser can escape that way - its expected and fine behaviour
>
> Does not work for me, and that would be the EXACT thing chroot is
> supposed to prevent.  Maybe you guys are thinking of a program that
> calls chroot() but leaves cwd outside the chroot still being able to
> navigate outside of it?

Oh, for fsck sake...  Folks, it's standard-required behaviour.  Ability
to chroot() implies the ability to break out of it.  Could we please
add that (along with reference to SuS) to l-k FAQ and be done with that
nonsense?

If you are within chroot jail and capable of chroot(), you can chdir to
its root, then chroot() to subdirectory and you've got cwd outside of
your new root.  After that you can chdir all way out to original root.

Again, this is standard behaviour.  Changing it will not yield any
security improvements, so kindly give that a rest.

From: Al Viro <viro@ftp.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: sys_chroot+sys_fchdir Fix
Date: Wed, 26 Sep 2007 18:41:32 UTC
Message-ID: <fa.Z+kjy0LxMAzlbiQQL9fglBQ2U70@ifi.uio.no>

On Wed, Sep 26, 2007 at 08:04:14PM +0930, David Newall wrote:
> Al Viro wrote:
> >Oh, for fsck sake...  Folks, it's standard-required behaviour.  Ability
> >to chroot() implies the ability to break out of it.  Could we please
> >add that (along with reference to SuS) to l-k FAQ and be done with that
> >nonsense?
>
> I'm pretty confident that it's only standard behavior for Linux.  Every
> other unix says it's not allowed.

OK, the possibilities are
	* you've discovered a bug in all Unices (BTW, even FreeBSD *does*
allow to break out of some chroots in that fashion; RTFS and you'll see -
just pay attention to setting fdp->fd_jdir logics in kern/vfs_syscalls.c:
change_root(); it sets jail boundary on _first_ chroot and if you've got
nested chroots, you can leave them just fine by use of SCM_RIGHTS to hold
directory descriptor).  All hail David, nevermind that this behaviour had
been described in Unix FAQs since _way_ back.
	* you've misunderstood the purpose of chroot(), the fact that
behaviour in question is at the very least extremely common on Unix and
the fact that any code relying on root-proof chroot(2) is broken and needs
to be fixed, simply because chroot is _not_ root-proof on (at least) almost
all systems.

Note that the last statement applies in both cases; it's simply reality.
Insisting that behaviour known for decades is a bug since it contradicts
your rather convoluted reading of the standards...  Looks rather silly,
IMO, but that has zero practical consequences anyway.  Userland code can't
rely on root-proof chroot(2), period.

From: Al Viro <viro@ftp.linux.org.uk>
Newsgroups: fa.linux.kernel
Subject: Re: sys_chroot+sys_fchdir Fix
Date: Thu, 27 Sep 2007 04:00:20 UTC
Message-ID: <fa.6oIPUq76TLuWkBUGEBsfDXjpOpM@ifi.uio.no>

On Thu, Sep 27, 2007 at 02:01:37AM +0200, Adrian Bunk wrote:
> <--  snip  -->
>
> Look, when chroot was being designed, I think they intended that even root
> should be unable to get out. They went so far as to say that dot-dot
> wouldn't let you out; and it doesn't.
>
> <--  snip  -->
>
> You were clearly saying that whom you call "they" were the people who
> designed chroot. And it was you who was claiming in this statement that
> "they" said it.
>
> The OpenBSD manpage you quoted in this thread states chroot() was added
> in 4.2BSD, and 4.2BSD was released in 1983.
>
> You should therefore either bring a source where the people who designed
> chroot() in 1983 or earlier are stating what you claim they said or
> admit that you were talking utter bullshit.

chroot() is present in v7, thank you very much.  /usr/sys/sys/sys4.c has

chdir()
{
        chdirec(&u.u_cdir);
}

chroot()
{
        if (suser())
                chdirec(&u.u_rdir);
}

and back then it didn't stop lookups by .. at all - u_rdir is only used
in the beginning of namei() (when pathname starts with /), plus the obvious
refcounting in exit()/newproc().  So give me a break - back when it had
been introduced, it didn't do anything jail-like _at_ _all_.

That check appears only in BSD:
@@ -1,4 +1,4 @@
-/*     vfs_lookup.c    4.4     03/06/81        */
+/*     vfs_lookup.c    4.5     81/03/09        */

 #include "../h/param.h"
 #include "../h/systm.h"
@@ -107,6 +107,9 @@
        u.u_segflg = 1;
        eo = 0;
        bp = NULL;
+       if (dp == u.u_rdir && u.u_dent.d_name[0] == '.' &&
+           u.u_dent.d_name[1] == '.' && u.u_dent.d_name[2] == 0)
+               goto cloop;

 eloop:

with spectaculary lousy commit message ("lint and a minor fixed") by
wnj.  Feel free to ask Bill Joy WTF he had intended.  At a guess,
more consistent behaviour in chrooted environment (i.e. pathname
resolution looking as if the subtree had been everything).

To talk about root-safety of _anything_ at that point is bloody ridiculous.

From: Theodore Tso <tytso@mit.edu>
Newsgroups: fa.linux.kernel
Subject: Re: sys_chroot+sys_fchdir Fix
Date: Thu, 27 Sep 2007 11:24:48 UTC
Message-ID: <fa.Kjgf4zYIodypxAP3fqko/1Bpvgw@ifi.uio.no>

On Thu, Sep 27, 2007 at 09:28:08AM +0200, Christer Weinigel wrote:
> So the OpenBSD man page seems to be in the minority here.  Any portable
> code can not assume that CWD changes.  And changing the Linux behaviour
> now would be a rather big change which might break userspace.  And yes,
> there are applications that rely on this, I've used it when building
> software for cross compiling.

Changing Linux behavior would violate the POSIX and SuSV2
specifications; the standards explicitly state that the working
directory will NOT change.  And standards adherance is important; we
break them only if we have a d*mn good reason.  And trying to make
chroot() something which it is not (i.e., a secure jail) is certainly
not a good enough reason.

Can we please end this thread now?  And can we put in a Kernel FAQ
saying that this is not something which is NOT up for discussion?

       	    	    		  	   - Ted