From owner-freebsd-security Fri Nov 1 23:04:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA12958 for security-outgoing; Fri, 1 Nov 1996 23:04:20 -0800 (PST) Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA12948 for ; Fri, 1 Nov 1996 23:04:15 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id XAA08490; Fri, 1 Nov 1996 23:04:03 -0800 (PST) From: Don Lewis Message-Id: <199611020704.XAA08490@salsa.gv.ssi1.com> Date: Fri, 1 Nov 1996 23:04:02 -0800 In-Reply-To: Marc Slemko "Re: chroot() security" (Nov 1, 11:38pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Marc Slemko , Don Lewis Subject: Re: chroot() security Cc: Dev Chanchani , freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 1, 11:38pm, Marc Slemko wrote: } Subject: Re: chroot() security } } A trivial solution would be to modify the kernel chroot routine to change } the current directory to something inside the chrooted directory, however } that solution is too trivial in that it would break some existing programs } and I'm not sure it would help anything because I would suggest that many } of the data structures involved could perhaps be manipulated using some } other method. This doesn't really help. A trivial way to break out would be for the process to fork(), the parent process could then chroot() to a subdirectory of the it's root directory, then chdir() to a subdirectory of it's new root directory. The child process could wait for the parent to arrive at it's new current directory, then rename() that directory to another location outside the the tree under parent's root directory. The parent can then walk up the tree to the real root, and then execute chroot() when it gets there. --- Truck