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: <46F924E3.50205@davidnewall.com>
Date:	Wed, 26 Sep 2007 00:40:27 +0930
From:	David Newall <david@...idnewall.com>
To:	"Serge E. Hallyn" <serge@...lyn.com>
CC:	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: Chroot bug (was: sys_chroot+sys_fchdir Fix)

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

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.

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.)
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ