linux-kernel - Re: [RFC][PATCH 0/3] vfs: Detach mounts on unlink.

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 05 Oct 2013 19:12:55 -0500
From:	Rob Landley <rob@...dley.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Miklos Szeredi <miklos@...redi.hu>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Linux-Fsdevel <linux-fsdevel@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>
Subject: Re: [RFC][PATCH 0/3] vfs: Detach mounts on unlink.

On 10/05/2013 06:17:55 PM, Linus Torvalds wrote:
> On Sat, Oct 5, 2013 at 4:07 PM, Rob Landley <rob@...dley.net> 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-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/