Message-ID: <20070927092808.612c204b@localhost.localdomain>
Date:	Thu, 27 Sep 2007 09:28:08 +0200
From:	Christer Weinigel <christer@...nigel.se>
To:	David Newall <david@...idnewall.com>
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

On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <david@...idnewall.com> wrote:

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

So keep reading the links I gave you:

    http://www.unixwiz.net/techtips/chroot-practices.html

    The chroot call itself does not change the working directory, so
    if the new root is below the current directory, the application
    can still have access outside resources.

    http://www.bpfh.net/simes/computing/chroot-break.html

    chdir("/foo/bar");
    chroot("/foo/bar");

    Note the use of the chdir() call before the chroot() call. This is
    to ensure that the working directory of the process is within the
    chroot()ed area before the chroot() call takes place. This is due
    to most implementations of chroot() not changing the working
    directory of the process to within the directory the process is
    now chroot()ed in.

    http://www.faqs.org/faqs/unix-faq/programmer/secure-programming/

    The chroot() call itself will only change the root file system in
    the process' context. A chroot() call must be followed by a
    chdir("/") call in order to reset the current working directory.

So the OpenBSD man page seems to be in the minority here.  Any portable
code can not assume that CWD changes.  And changing the Linux behaviour
now would be a rather big change which might break userspace.  And yes,
there are applications that rely on this, I've used it when building
software for cross compiling.  

  /Christer

On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <david@...idnewall.com> wrote:

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

Powered by blists - more mailing lists