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>