Message-ID: <Pine.LNX.4.58.0709262046350.3113@be1.lrz>
Date:	Wed, 26 Sep 2007 21:23:23 +0200 (CEST)
From:	Bodo Eggert <7eggert@....de>
To:	David Newall <david@...idnewall.com>
cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	Bill Davidsen <davidsen@....com>,
	Philipp Marek <philipp@...ek.priv.at>, 7eggert@....de,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	majkls <majkls@...pere.com>, bunk@...tum.de,
	linux-kernel@...r.kernel.org
Subject: Re: Chroot bug (was: sys_chroot+sys_fchdir Fix)

On Wed, 26 Sep 2007, David Newall wrote:

> Miloslav Semler pointed out that a root process can chdir("..") out of 
> its chroot.  Although this is documented in the man page, it conflicts 
> with the essential function, which is to change the root directory of 
> the process.

The root directory, '/' is changed, and if the process is capable of using
chroot, it may change the root directory again. Works as defined.

>  In addition to any creative uses, for example Philipp 
> Marek's loading dynamic libraries, it seems clear that the prime purpose 
> of chroot is to aid security.

As long as root has more than a safe subset of capabilities, root can escape 
a chroot.

Besides that, fchdir on open-at-chroot fds does not decrease the security, 
since the attacker needs help from the outside root, who is not restricted 
by chroot.

I'm more concerned about abstract unix sockets, they could be used to 
send a file descriptor to compromised daemons and extend exploits to
the outside of a chroot and across namespaces - at least I suspect it.
The whole f* family of syscalls would be affected. This can be cured by
e.g. not allowing to receive fds if the root+namespace do not match.

>  Being able to cd your way out is handy 
> for the bad guys, but the good guys don't need it; there are a thousand 
> better, safer solutions.

The good guys don't cd out, they open the instalkler archive, chroot to the 
new system root and extract it there. Then they chroot back using the saved 
cwd.

> If there truly is a need to be able to pop in and out of a chroot, then 
> the solution should be obvious, such as with real versus effective user 
> and group ids.  An important quality of a solution would be a way to fix 
> that essential function: to set the root in such a way that you can no 
> longer pop out.  But that is a separate question.

As in jail()?

As far as I know, the new virtualisation features sneaking into the kernel  
will allow implementing a jail, too, in a more secure way than any hacking 
on chroot can give.

> The question: is chroot buggy?  I'm pleased to turn to SCO for an 
> independent definition for chroot, from which I get the following:
> 
> http://osr600doc.sco.com/en/man/html.S/chroot.S.html:
> >
> > The *..* entry in the root directory is interpreted to mean the root 
> > directory itself. Thus, *..* cannot be used to access files outside 
> > the subtree rooted at the root directory.
> >
> 
> I argue chroot is buggy.  Miloslav's patch might not be the right 
> solution, but he has the right idea (i.e. fix it.)

There are implementations of chroot which imply chdir(), and not having f* 
functions, they can not _directly_ acces files outside the chroot. But as 
long as they can e.g. mknod /dev/mem or strace, they can do anything.

So let's not put a fingerprint sensor on that chinese paper door.
-- 
You know you're in trouble when packet floods are competing to flood you.
	-- grc.com
-
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/

Powered by blists - more mailing lists