From owner-freebsd-security Mon Jul 7 13:39:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA06866 for security-outgoing; Mon, 7 Jul 1997 13:39:54 -0700 (PDT) Received: from shell.firehouse.net (brian@shell.firehouse.net [209.42.203.45]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA06849 for ; Mon, 7 Jul 1997 13:39:49 -0700 (PDT) Received: from localhost (brian@localhost) by shell.firehouse.net (8.8.5/8.8.5) with SMTP id QAA16773; Mon, 7 Jul 1997 16:39:03 -0400 (EDT) Date: Mon, 7 Jul 1997 16:39:01 -0400 (EDT) From: Brian Mitchell To: Robert Watson cc: Sean Eric Fagan , security@FreeBSD.ORG Subject: Re: Security Model/Target for FreeBSD or 4.4? 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 Mon, 7 Jul 1997, Robert Watson wrote: > On a related note, has anyone given any thought to making chroot() a > user-accessible call? I haven't really looked at it, so am not sure why > it can only be called by uid root programs. In terms of sandboxing (which > seems to be popular these days for various applications), it would be nice > to restrict programs to specific regions of the disk, etc. Especially if > you are a non-root user developing programs that require special > libraries, etc. Or if you want to run a restricted web or ftp server, but > don't have root access (as hopefully would be the case with the lighter > restrictions on binding ports <1024.) picture this, /usr/home is the same fs as /usr/bin - you create a reasonable tree with its own passwd file, you populate your usr/bin with hardlinks, you chroot and run su su will read your passwd file, giving you root. you create a setuid shell or something similar and then log out of the shell and go back to the nonchrooted environment and run the suid root shell. Brian Mitchell brian@firehouse.net "BSD code sucks. Of course, everything else sucks far more." - Theo de Raadt