Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 3 Nov 1996 19:07:36 -0800
From:      Don Lewis <Don.Lewis@tsc.tdk.com>
To:        "Daniel O'Callaghan" <danny@panda.hilink.com.au>, Dev Chanchani <dev@trifecta.com>
Cc:        Marc Slemko <marcs@znep.com>, freebsd-security@freebsd.org
Subject:   Re: chroot() security
Message-ID:  <199611040307.TAA10244@salsa.gv.ssi1.com>
In-Reply-To: "Daniel O'Callaghan" <danny@panda.hilink.com.au> "Re: chroot() security" (Nov  4, 10:38am)

next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 4, 10:38am, "Daniel O'Callaghan" wrote:
} Subject: Re: chroot() security
} 
} Also, a couple of years ago this sort of stuff was discussed on 
} firewalls@greatcircle.com.  I think it was Marcus Ranum, author of FWTK, 
} who posted a fix for the unchroot problem.  Essentially: there is 
} one root inode, which is normally 0.  After a chroot() it is no longer 
} 0.  If you wish to prevent all processes from breaking out of a 
} chroot()ed area, it is simple to deny chroot() calls to processes which 
} have root inode != 0.  

Yes, this is one possible fix ...

} This hardening is good, but it has its limitations. ftpd which has been
} run prechroot()ed, cannot operate as anonymous (or if wu-ftpd as a
} guest-class user) because it cannot chroot() again.  Probably not an
} insurmountable problem, but it does limit the usefulness of the 'fix'
} described above. 

and this is it's biggest problem.

} Can anyone think of a way to determine whether a chroot() is "upwards"
} or "downwards"?  It would be nice to be able to allow chroot()s deeper 
} into the tree, but not "upwards".

This isn't secure against the exploit by cooperating processes that I
posted a couple days ago.  One process can do a chroot() deeper into
the tree and chdir() to a subdirectory of that directory, then the other
process can rename() that directory outside the tree under the first
process' root directory.

The most flexible and secure fix would be to treat the root directory
as an append-only list.  Pathname translations starting with / would
use the last list entry, and upward movement using "..", would stop when
encountering any members of the list.  Of course, there are other potential
problems unless you limit the length of the list.  I implemented something
equivalent to this with a fixed list length of two.

			---  Truck



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611040307.TAA10244>