linux-kernel - Re: sys_chroot+sys

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]

Date:	Thu, 27 Sep 2007 06:49:28 +0930
From:	David Newall <david@...idnewall.com>
To:	Christer Weinigel <christer@...nigel.se>
CC:	Al Viro <viro@....linux.org.uk>, Phillip Susi <psusi@....rr.com>,
	Bill Davidsen <davidsen@....com>, majkls <majkls@...pere.com>,
	bunk@...tum.de, linux-kernel@...r.kernel.org
Subject: Re: sys_chroot+sys_fchdir Fix

Christer Weinigel wrote:
> *spends five minutes with Google*
>
> From the OpenBSD FAQ (an operating system most know for being really,
> really focused on security):
>
>     http://www.openbsd.org/faq/faq10.html
>
>     Any application which has to assume root privileges to operate is
>     pointless to attempt to chroot(2), as root can generally escape a
>     chroot(2).
>   

For sure, "a root user can get out of a chroot a million different 
ways."  Young Alan said as much at the beginning of this conversation, 
and I have always agreed.  I don't hope to secure Linux within chroot, 
simply to fix chroot so that it does what it says it does.

Look, when chroot was being designed, I think they intended that even 
root should be unable to get out.  They went so far as to say that 
dot-dot wouldn't let you out; and it doesn't.  It's not dot-dot that's 
the problem.  Even fchdir is no problem, because you choose which file 
descriptors to leave open.  Fchdir is actually one of the answers.  
("What if we need a way to escape?")

The problem is leaving cwd unchanged.  Once you've set cwd within the 
new root, dot-dot is promised to keep you within that root; and so it 
does.  But by leaving cwd unchanged, if you do a subsequent chroot, that 
promise is suddenly broken.  I think this is a bug.  I think that 
behavior was not intended.  Not all agree with me, but obviously a lot 
do, otherwise OpenBSD and others wouldn't have addressed this exact 
issue.  Here's what they do:

    "If the program is already running with an altered root directory,
    the process's current directory is changed to the same new root
    directory.  This prevents the current directory from being further
    up the directory tree than the altered root directory."
    -- OpenBSD man 2 chroot

This was no more than an attempt to fix a long-standing bug.

As stated, opinion is divided as to whether this is a bug.  I think it 
is, and many people agree, for example some of the BSDs and probably 
others; some people don't.  Young Alan, for example, ummm, strongly (is 
a good word) disagrees.  I don't see that it calls for nastiness or 
emotion, and although opinion on this august list is divided, apparently 
the nays are in the majority.  We should leave it at that.
-
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/