[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: chroot

(I've been talking with Alan about the chroot(2) manpage.)

On Sun, 7 Oct 2001 20:30:50 +0200 Christian Jaeger
<christian.jaeger@sl.ethz.ch> wrote:
> On Sun, 07 Oct 2001 14:07:56 -0400 Alan Shutko <ats@acm.org> wrote:
> > Christian Jaeger <christian.jaeger@sl.ethz.ch> writes:
> > 
> > > Which one? I don't see anything in the manpage from debian potato
> (1997).
> > 
> > Must have been added recently, then.  Here's the version in
> > 
> >        Note that this call does not change  the  current  working
> >        directory,  so  that `.' can be outside the tree rooted at
> >        `/'.  In particular, the  super-user  can  escape  from  a
> >        `chroot jail' by doing `mkdir foo; chroot foo; cd ..'.
> Yep, that's alread in the old manpage. For this reason it's very
> important to chdir inside the chrooted tree before doing the chroot
> call. (The chroot binary does this, as hopefully do all other programs
> using chroot for security purposes). If you do that, the risk isn't
> there anymore.

Hmmmm, at first glance it even looks like a mistake in the chroot(2)
manpage (from woody - in potato there's only the first of the two above
sentences): `mkdir foo; chroot foo; cd ..' does *not* escape foo, at
least not with the chroot command in potato (kernel 2.4.7).

Well I've downloaded the source shellutils package from both stable and
unstable and am looking at the chroot source (it's the same in both -
the only difference is the newer chroot does "atexit (close_stdout);"
before the chroot):

  if (chroot (argv[1]))
    error (1, errno, _("cannot change root directory to %s"), argv[1]);

  if (chdir ("/"))
    error (1, errno, _("cannot chdir to root directory"));

In fact, a strace shows:
close(3)                                = 0
chroot("testchroot/")                   = 0
chdir("/")                              = 0
execve("/bin/bash", ["/bin/bash", "-i"], [/* 25 vars */]) = 0

Which I would think is just the *wrong* way round! ?? So either the
current chroot binary has a security problem, or the kernel drops '..'
and '.' dirs when doing chdir / after chroot.


Reply to: