Date: Mon, 4 Nov 1996 10:38:55 +1100 (EST) From: "Daniel O'Callaghan" <danny@panda.hilink.com.au> To: Dev Chanchani <dev@trifecta.com> Cc: Marc Slemko <marcs@znep.com>, freebsd-security@freebsd.org Subject: Re: chroot() security Message-ID: <Pine.BSF.3.91.961104100846.1188B-100000@panda.hilink.com.au> In-Reply-To: <Pine.BSF.3.91.961103150038.3636A-100000@www.trifecta.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Nov 1996, Dev Chanchani wrote: > > telnetd@192.168.0.1 : \ > > .example.com : \ > > rfc931 : severity auth.info : \ > > twist = /usr/sbin/chroot /directory/to/chroot/to /usr/libexec/telnetd I achieved the same result by adding a switch -switchbyip to work with -chroot switch in the Firewall Toolkit netacl.c. Simply appends the ip address to the target chroot directory, so /chroot -> /chroot/192.3.4.5 netacl.c *does* chdir() before chroot()ing. 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. I'm not a FS hacker, and it is two years since I read the posting, but I think you'll get the idea. I think this is similar to PHK's posting, apart from the killing of the process. The code to do the above is about 2 lines, from my hazy memory. 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. 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". Danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.961104100846.1188B-100000>