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 ; 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 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