linux-kernel - Re: 2.6.18 - check for chroot, broken root and cwd values in procfs

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] [day] [month] [year] [list]

Message-ID: <20061021101623.GB1709@1wt.eu>
Date:	Sat, 21 Oct 2006 12:16:23 +0200
From:	Willy Tarreau <w@....eu>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Bastian Blank <bastian@...di.eu.org>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...l.org>,
	Linus Torvalds <torvalds@...l.org>
Subject: Re: 2.6.18 - check for chroot, broken root and cwd values in procfs

On Fri, Oct 13, 2006 at 09:02:50PM -0600, Eric W. Biederman wrote:
> Bastian Blank <bastian@...di.eu.org> writes:
> 
> > On Thu, Oct 12, 2006 at 04:02:24PM +0200, Bastian Blank wrote:
> >> The commit 778c1144771f0064b6f51bee865cceb0d996f2f9 replaced the old
> >> root-based security checks in procfs with processed based ones.
> >
> > The new behaviour even allows a user to escape from the chroot by using
> > chdir to /proc/$pid/cwd or /proc/$pid/root of a process he owns and
> > lives outside of the chroot.
> 
> Yep.  It makes it obvious that you can do that.
> 
> If you were in a chroot you could always ptrace a process you own
> that was outside of the chroot, and cause it to do things, such as
> open a unix domain socket and pass you it's current root directory.

yes, but it's a bit trickier than remotely telling a script to basically
do chdir("/proc/1/cwd").

> chroot by itself has never been much of a jail.

OK, but that's not a reason for breaking trivial protection against
trivial escape methods.

Also, people sometimes compose build environments using chroot, which
at least protect them from accidental escape and corruption of the root
FS. It is a bit scary to know that a poorly designed install script
could break out of the chroot by abusing /proc or simply doing dirty
things such as "find / -follow" for any valid purpose under such an
environment.

Chroot is a useful tool for build and test environments, it's dangerous
to break it that way.

I'd clearly prefer that tasks outside the chroot show broken links
for cwd, root and exe under /proc.

Regards,
willy

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