From owner-freebsd-security Sun Nov 3 15:42:34 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA12842 for security-outgoing; Sun, 3 Nov 1996 15:42:34 -0800 (PST) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA12592 for ; Sun, 3 Nov 1996 15:39:50 -0800 (PST) Received: (from danny@localhost) by panda.hilink.com.au (8.7.6/8.7.3) id KAA01481; Mon, 4 Nov 1996 10:38:58 +1100 (EST) Date: Mon, 4 Nov 1996 10:38:55 +1100 (EST) From: "Daniel O'Callaghan" To: Dev Chanchani cc: Marc Slemko , freebsd-security@freebsd.org Subject: Re: chroot() security In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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