public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christer Weinigel <christer@weinigel.se>
To: David Newall <david@davidnewall.com>
Cc: Al Viro <viro@ftp.linux.org.uk>, Phillip Susi <psusi@cfl.rr.com>,
	Bill Davidsen <davidsen@tmr.com>, majkls <majkls@prepere.com>,
	bunk@fs.tum.de, linux-kernel@vger.kernel.org
Subject: Re: sys_chroot+sys_fchdir Fix
Date: Thu, 27 Sep 2007 09:28:08 +0200	[thread overview]
Message-ID: <20070927092808.612c204b@localhost.localdomain> (raw)
In-Reply-To: <46FACCE0.2070005@davidnewall.com>

On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <david@davidnewall.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@davidnewall.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.
> 

  parent reply	other threads:[~2007-09-27  7:28 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-19  7:19 sys_chroot+sys_fchdir Fix majkls
2007-09-19  9:40 ` Alan Cox
2007-09-19 18:27   ` Bill Davidsen
2007-09-19 18:45     ` Alan Cox
2007-09-19 22:24       ` David Newall
2007-09-21 17:39         ` Phillip Susi
2007-09-21 18:10           ` Alan Cox
2007-09-25 20:53             ` Phillip Susi
2007-09-26  0:23               ` Al Viro
2007-09-26 10:34                 ` David Newall
2007-09-26 11:21                   ` Alan Cox
2007-09-26 11:22                     ` David Newall
2007-09-26 11:38                       ` Alan Cox
2007-09-26 11:56                         ` David Newall
2007-09-26 14:10                           ` Alan Cox
2007-09-26 15:03                             ` Chris Adams
2007-09-26 16:54                             ` David Newall
2007-09-26 17:04                               ` Alan Cox
2007-09-26 17:18                                 ` David Newall
2007-09-26 17:29                                   ` Alan Cox
2007-09-26 17:28                                     ` David Newall
2007-09-26 18:40                   ` Al Viro
2007-09-26 19:24                   ` Christer Weinigel
2007-09-26 21:19                     ` David Newall
2007-09-26 21:55                       ` Adrian Bunk
2007-09-26 23:35                         ` David Newall
2007-09-27  0:01                           ` Adrian Bunk
2007-09-27  3:59                             ` Al Viro
2007-09-27  6:42                             ` David Newall
2007-09-27  6:53                               ` Adrian Bunk
2007-09-27  7:28                       ` Christer Weinigel [this message]
2007-09-27 11:23                         ` Theodore Tso
2007-09-27 14:36                           ` Bill Davidsen
2007-09-28  1:06                             ` David Newall
     [not found] <952DN-83o-31@gated-at.bofh.it>
     [not found] ` <954cl-29C-3@gated-at.bofh.it>
     [not found]   ` <95ctn-74b-15@gated-at.bofh.it>
     [not found]     ` <95cMH-7um-19@gated-at.bofh.it>
     [not found]       ` <95gdA-4OZ-7@gated-at.bofh.it>
2007-09-20 11:13         ` Bodo Eggert
2007-09-20 11:59           ` Philipp Marek
2007-09-20 12:52             ` majkls
2007-09-20 16:06             ` David Newall
2007-09-20 16:17               ` Philipp Marek
2007-09-20 18:02                 ` David Newall
2007-09-20 20:53                   ` Bill Davidsen
2007-09-21  8:29                     ` David Newall
2007-09-24 21:32                       ` Serge E. Hallyn
2007-09-24 22:04                         ` David Newall
2007-09-24 23:00                           ` Serge E. Hallyn
2007-09-25  7:45                             ` David Newall
2007-09-25 11:49                               ` Serge E. Hallyn
2007-09-25 13:58                                 ` David Newall
2007-09-24 23:02                           ` Serge E. Hallyn
     [not found]         ` <95UE2-1oR-19@gated-at.bofh.it>
     [not found]           ` <95V72-2ly-17@gated-at.bofh.it>
     [not found]             ` <97pG8-3B5-47@gated-at.bofh.it>
     [not found]               ` <97sX2-p1-3@gated-at.bofh.it>
2007-09-26  9:38                 ` Nick Craig-Wood
     [not found] <fa.1U6+49SWHSlhuK5/3PBckFWAbXU@ifi.uio.no>
     [not found] ` <fa.WASh5K8oOF4DAq3sSYtIlWNCdWQ@ifi.uio.no>
     [not found]   ` <fa.X6MeYG+PmN8/e5zfGij80quLaws@ifi.uio.no>
     [not found]     ` <fa./eIdqiAY0Mx9xHl6ESobHaLKJBM@ifi.uio.no>

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070927092808.612c204b@localhost.localdomain \
    --to=christer@weinigel.se \
    --cc=bunk@fs.tum.de \
    --cc=david@davidnewall.com \
    --cc=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=majkls@prepere.com \
    --cc=psusi@cfl.rr.com \
    --cc=viro@ftp.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox