From owner-freebsd-security Mon Feb 24 05:37:11 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id FAA19373 for security-outgoing; Mon, 24 Feb 1997 05:37:11 -0800 (PST) Received: from profane.iq.org (profane.iq.org [203.4.184.217]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA19358; Mon, 24 Feb 1997 05:36:36 -0800 (PST) Received: (from proff@localhost) by profane.iq.org (8.8.4/8.8.2) id AAA10815; Tue, 25 Feb 1997 00:28:34 +1100 (EST) From: Julian Assange Message-Id: <199702241328.AAA10815@profane.iq.org> Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments In-Reply-To: <2530.856709842@critter.dk.tfs.com> from Poul-Henning Kamp at "Feb 23, 97 03:57:22 pm" To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Tue, 25 Feb 1997 00:28:33 +1100 (EST) Cc: hackers@freebsd.org, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] 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 > >It is restricted to non-suid, just the same as LD_PRELOAD is. There > >is an "unsafe" field in the scan_tab for all enviromental variables > >used by ld.so. It's set to on for LD_CHROOT. You may want to have > >a look at this before presuming I'm a complete fool ;) > > Listen, this patch is maybe or maybe not correct, but it certainly > is pointless. > > For anything as little used as chroot to clobber the one of the most > timecritical piece of code in userland is simply not an option, in > particular where there isn't any better argumentation that "it would > be neat of one could..." > > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. Have you actually ever looked at rtld.c? Alone it over 53k long. It is full of debug code that is normally never used. A p-100 class machine does around 173,000 getenv("LD_CHROOT")'s a second. What plannet are you on? The primary reason chroot() is rarely used is because it is painful to use. LD_CHROOT makes it very, very easy to use. That said, I have absolutely no doubt chroot() is used more than LD_LIBRARY_PATH, LD_PRELOAD, LD_IGNORE_MISSING_OBJECTS, LD_TRACE_LOADED_OBJECTS, LD_BIND_NOW, LD_SUPPRESS_WARNINGS and LD_WARN_NON_PURE_CODE put together. It would be neat if one could actually use the chroot() facility in a secure and efficient manner, without modifying the source for main() on every binary in the system. You are right. It would be neat. Since when is something being small, fast, secure, neat and providing functionality that wouldn't otherwise be there grounds for rejection of code? I'm quite apalled at this conservative view, expressed without the slightest understanding of the code involved. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@iq.org |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery