From owner-freebsd-hackers Tue Aug 25 14:22:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA08136 for freebsd-hackers-outgoing; Tue, 25 Aug 1998 14:22:19 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fledge.watson.org (COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA08017 for ; Tue, 25 Aug 1998 14:22:07 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id RAA00103; Tue, 25 Aug 1998 17:20:46 -0400 (EDT) Date: Tue, 25 Aug 1998 17:20:46 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Joel Ray Holveck cc: dpk@notreal.com, garbanzo@hooked.net, rabtter@aye.net, hackers@FreeBSD.ORG Subject: Re: I want to break binary compatibility. In-Reply-To: <199808251922.OAA00955@detlev.UUCP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Aug 1998, Joel Ray Holveck wrote: > > My favored choice would be to modify the standard dynamic link support to > > check /etc/ld.conf (or a sysctl) to determine whether the system policy > > currently allowed dynamic linking or not, and if so, whether user-defined > > paths were allowed. This, in combination with the bless-support would > > work pretty well. > > Would /etc/ld.conf be vulnerable to chroots? > > Best, > joelh I was tempted to make the code be influenced by a sysctl -- something that can be read regardless of environment, and would give an indication of the current system policy. However, this is the same problem we keep running into -- I wonder if there is a better solution? chroot causes us a number of problems with code trusting file trees to provide a reliable source for policy and security information. We see libraries (getpwent, etc) consistently relying on the accuracy of paths for reaching resources. However, then we see chroot attempting to provide security by "sandboxing" while at the same time undermining the security mechanisms provided by the remainder of the operating system. It is the desire to have variable file trees displayed to different applications at the same time as having a unique and enforced file tree displayed. This type of sandboxing does not fit well into the standard UNIX model. It might be better served in a dynamic code + message based architecture (such as some combination of Java and Mach). Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message