From owner-freebsd-security  Sun Nov  3 19:28:29 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA03698
          for security-outgoing; Sun, 3 Nov 1996 19:28:29 -0800 (PST)
Received: from salsa.gv.ssi1.com (salsa.gv.ssi1.com [146.252.44.194])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA03681
          for <freebsd-security@FreeBSD.ORG>; Sun, 3 Nov 1996 19:28:25 -0800 (PST)
Received: (from gdonl@localhost) by salsa.gv.ssi1.com (8.7.5/8.7.3) id TAA10276; Sun, 3 Nov 1996 19:27:55 -0800 (PST)
From: Don Lewis <Don.Lewis@tsc.tdk.com>
Message-Id: <199611040327.TAA10276@salsa.gv.ssi1.com>
Date: Sun, 3 Nov 1996 19:27:55 -0800
In-Reply-To: Poul-Henning Kamp <phk@critter.tfs.com>
       "Re: chroot() security" (Nov  2, 10:38am)
X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95)
To: Poul-Henning Kamp <phk@critter.tfs.com>, Marc Slemko <marcs@znep.com>
Subject: Re: chroot() security
Cc: Don Lewis <Don.Lewis@tsc.tdk.com>, Dev Chanchani <dev@trifecta.com>,
        freebsd-security@FreeBSD.ORG
Sender: owner-security@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Nov 2, 10:38am, Poul-Henning Kamp wrote:
} Subject: Re: chroot() security
} In message <Pine.BSF.3.95.961101225850.22655K-100000@alive.ampr.ab.ca>, Marc Sl
} emko writes:
} >Yup, you certainly can add checks and in theory you should be able to plug
} >all the holes IF you can find them.  My bet is that you won't be able to
} >find them, so you can't make it secure.
} 
} One simple way is to disallow processes that have any *uid == 0 in the
} chroot tree.   I did this once by comparing the rootfs pointer to that
} of pid == 1 and if it was different and one of the uid's were zero
} I killed the process.
} 
} The few operations that needed to do root things, sent a message over
} a tcp pipe to a local process that would examine what process was at the
} other end of the pipe and do the stuff to it if it made sense.  That
} daemon ran outside the chroot env.

I'm not convinced this is more secure.  It may be possible for the chroot()ed
process to trick the non-chroot()ed process into doing something bad, perhaps
by following a /some/path/outside/chroot symlink that the chroot()ed process
created in the chroot() environment.  If the root process was also chroot()ed,
then the damage it does would be contained within that environment, unless
it could be tricked into arbitrary code (via a buffer overflow exploit, etc.)
to get it out of that environment.  If the latter is possible, then you're
already in deeper yogurt if the root process is not chroot()ed.

			---  Truck