From owner-freebsd-security Wed Jul 9 15:10:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA15531 for security-outgoing; Wed, 9 Jul 1997 15:10:48 -0700 (PDT) Received: from burgundy.eecs.harvard.edu (dholland@burgundy.eecs.harvard.edu [140.247.60.165]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA15526 for ; Wed, 9 Jul 1997 15:10:37 -0700 (PDT) Received: (from dholland@localhost) by burgundy.eecs.harvard.edu (8.8.5/8.8.5) id SAA11291; Wed, 9 Jul 1997 18:09:42 -0400 (EDT) From: David Holland Message-Id: <199707092209.SAA11291@burgundy.eecs.harvard.edu> Subject: Re: Security Model/Target for FreeBSD or 4.4? To: newton@communica.com.au (Mark Newton) Date: Wed, 9 Jul 1997 18:09:42 -0400 (EDT) Cc: robert@cyrus.watson.org, newton@communica.com.au, sef@kithrup.com, security@FreeBSD.ORG In-Reply-To: <9707090029.AA06358@communica.com.au> from "Mark Newton" at Jul 9, 97 09:59:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Study the code carefully in light of this discussion. Realize that > providing arbitrary users with the ability to run chroot() would allow > arbitrary users to break out of sandboxen. There are two ways to fix this: (1) disallow chroot(8) if a chroot has already been performed, that is, the process's root is not the same as the global root, or (2) fix the mechanism that prevents "cd .." from the chrooted root so that if you set a new root directory it doesn't permit going up past the previous root directory. (If this is what your patch did, never mind.) It's not at all clear that fixing this is sufficient to keep root in a chroot area, though. The general opinion in many circles is that it's too hard to accomplish that and not worth trying. -- - David A. Holland | VINO project home page: dholland@eecs.harvard.edu | http://www.eecs.harvard.edu/vino