From owner-freebsd-security  Fri Oct  8 14:11:46 1999
Delivered-To: freebsd-security@freebsd.org
Received: from fever.semiotek.com (H253.C225.tor.velocet.net [216.126.82.253])
	by hub.freebsd.org (Postfix) with ESMTP id 15CFD15284
	for <freebsd-security@freebsd.org>; Fri,  8 Oct 1999 14:11:42 -0700 (PDT)
	(envelope-from jread@fever.semiotek.com)
Received: (from jread@localhost)
	by fever.semiotek.com (8.9.3/8.9.3) id RAA01803
	for freebsd-security@freebsd.org; Fri, 8 Oct 1999 17:12:38 -0400 (EDT)
	(envelope-from jread)
Date: Fri, 8 Oct 1999 17:12:37 -0400
From: Justin Wells <jread@semiotek.com>
To: freebsd-security@freebsd.org
Subject: more on chroot: "nochroot" filesystems
Message-ID: <19991008171237.B1618@fever.semiotek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


One more thing, a suggestion this time...

I lurked through the previous discussion of chroot and it's been sitting
in my mind ever since, fermenting. Here's a possible solution that wouldn't
do too much damage to the standard chroot behavior:

Add an option, similar to nodev and noexec, to the UFS filesystem called
"nochroot". You are only allowed to chroot if the root of the filesystem
you are currently in allows chroot. 

Thus the first chroot (with / as its root) would succeed because / allows
chroot, but its target would be inside a filesystem with the nochroot 
flag. Further chroots would be disallowed. 

This solution has zero effect by default, since by default chroot is 
allowed. Only people who ask for this behavior by specifying the mount
option would have the restriction imposed on them.

This defeats the "cd ../../../../../.. ; chroot ." trick, and many others.

Justin



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message