linux-kernel - Re: Chroot bug

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]

Message-Id: <6BA6E9EE-B67B-4334-AC83-9B8E30527832@mac.com>
Date:	Wed, 26 Sep 2007 08:54:35 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	David Newall <david@...idnewall.com>
Cc:	Adrian Bunk <bunk@...nel.org>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Bill Davidsen <davidsen@....com>,
	Philipp Marek <philipp@...ek.priv.at>, 7eggert@....de,
	majkls <majkls@...pere.com>, bunk@...tum.de,
	linux-kernel@...r.kernel.org
Subject: Re: Chroot bug

On Sep 26, 2007, at 06:27:38, David Newall wrote:
> Kyle Moffett wrote:
>> David, please do tell myself and Adrian how "locking down" chroot 
>> () the way you want will avoid letting root break out through any  
>> of the above ways?
>
> As has been said, there are thousands of ways to break out of a  
> chroot.  It's just that one of them should not be that chroot lets  
> you walk out.  I can't explain it clearer than that.  If you don't  
> see it now you probably never will.

Let me put it this way:  You *CANNOT* enforce chroot() the way you  
want to without a completely unacceptable performance penalty.  Let's  
start with the simplest example of:

fd = open("/", O_DIRECTORY);
chroot("/foo");
fchdir(fd);
chroot(".");

If you had ever actually looked at the Linux VFS, it is completely  
*impossible* to tell whether "fd" at the time of the chroot is inside  
or outside of "/foo" without tracking an enormous amount of extra  
state.  Even then, any such determination may not be valid since an  
FD may be opened to an inode which is hardlinked at multiple  
locations in the directory tree.  It could also be bind-mounted at  
multiple locations, or it may not even be mounted at all in this  
namespace (CDROM that was lazy-unmounted).  That FD may be later  
passed over an open UNIX-domain socket from another process.   
Moreover, arbitrarily closing FDs would break a huge number of  
programs.  Furthermore, since you can't fix the "trivial" case of  
'fchdir()', then there's no point in even *attempting* to fix the  
"cwd is outside of chroot" problem, although that is basically  
equivalent in difficulty to fixing the "dir-fd is outside of chroot"  
problem.

As for the nested-chroot() bit, the root user inside of a chroot is  
always allowed to chroot().  This is necessary for test-suites for  
various distro installers, chroot once to enter the installer  
playpen, installer chroots again to configure the test-installed- 
system.  Once you allow a second chroot, you're back at the "can't  
reliably and efficiently track directory sub-tree members" problem.

So if you think it can and should be fixed, then PROVIDE THE CODE.

Cheers,
Kyle Moffett

-
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/