From owner-freebsd-hackers  Sun Feb 23 00:16:11 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id AAA27955
          for hackers-outgoing; Sun, 23 Feb 1997 00:16: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 AAA27891;
          Sun, 23 Feb 1997 00:15:49 -0800 (PST)
Received: (from proff@localhost)
          by profane.iq.org (8.8.4/8.8.2) id TAA10018;
          Sun, 23 Feb 1997 19:10:20 +1100 (EST)
From: Julian Assange <proff@iq.org>
Message-Id: <199702230810.TAA10018@profane.iq.org>
Subject: Re: o [1997/02/01] bin/2634 rtld patches for easy creation of chroot enviroments
In-Reply-To: <199702210853.QAA15189@spinner.DIALix.COM> from Peter Wemm at "Feb 21, 97 04:53:33 pm"
To: peter@spinner.DIALix.COM (Peter Wemm)
Date: Sun, 23 Feb 1997 19:10:20 +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-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> What's to stop a user from setting LD_CHROOT to a "hostile" invironment,
> running a setuid program (which ignores LD_CHROOT), which happens to set
> it's uid's to the new id, and that process exec's some binary with uid ==
> euid now, so that new binary now takes note of LD_CHROOT and is now
> vulnerable to the "hostile" chroot environment...

Same argument applies to all the LD_* variables. This technique was used
to undermine the sync:: account under sunos with login -p etc

> Also, wouldn't this be better in crt0.c so it'd be usable for statically 
> linked binaries?

crt0.c should be as minimal as possible (since it is linked with
all code) , and the crt0.c solution requires relinking of all
binaries (which may not be possible). Further, statics don't have as
much need for this type of thing.

> Hmm.. another thing..  Once the chroot has happened, nothing removes the 
> LD_CHROOT variable from the environment..  Any sub processes will also try 
> to chroot within the chroot space..  This chould be a bit noisy.. :-]

You shouldn't be running sub-processes in the chroot space that
are dynamically linked, because they won't be able to get at the
shlibs or ld.so.  None-the-less it is probably worthwhile zorching
LD_CHROOT when chroot() is called.

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