linux-kernel - Re: sys_chroot+sys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 27 Sep 2007 04:59:26 +0100
From:	Al Viro <viro@....linux.org.uk>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	David Newall <david@...idnewall.com>,
	Christer Weinigel <christer@...nigel.se>,
	Phillip Susi <psusi@....rr.com>,
	Bill Davidsen <davidsen@....com>, majkls <majkls@...pere.com>,
	linux-kernel@...r.kernel.org
Subject: Re: sys_chroot+sys_fchdir Fix

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/