Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!cmcl2!husc6!talcott!maynard!campbell
From: campbell@maynard.UUCP (Larry Campbell)
Newsgroups: net.unix-wizards
Subject: Re: chroot(2) security
Message-ID: <358@maynard.UUCP>
Date: Sat, 4-Oct-86 10:45:55 EDT
Article-I.D.: maynard.358
Posted: Sat Oct  4 10:45:55 1986
Date-Received: Mon, 6-Oct-86 18:38:15 EDT
References: <158@itcatl.UUCP> <113@nonvon.UUCP> <233@BMS-AT.UUCP> <1669@bucsd.bu-cs.BU.EDU>
Reply-To: campbell@maynard.UUCP (Larry Campbell)
Organization: The Boston Software Works Inc., Maynard, MA
Lines: 22

In article <1669@bucsd.bu-cs.BU.EDU> jdh@bucsd.UUCP (Jason Heirtzler) writes:

>Modifying the executable image of su(1), isn't necessary to create
>a loop hole. An unscrupulus user that could use chroot could put HIS
>copy of /etc/passwd in /mnt23/user/test/etc/passwd, and also make a
>hard link from /mnt23/user/test/bin/login to /bin/login; then execve(2)
>(the calling process would inherit the process's root directory)
>to (the link of) the login program...

>The point of all of this being that the fundamental reason chroot(2)
>can't be patched to allow everyone to use it is that hard links 
>(though not soft links) are the real cause of the security loop
>hole with chroot.

This only works if /bin and /mnt23/user/test/bin are on the same
filesystem.  Most of the systems I know put user files and /bin on
different filesystems.  It seems to me that if /mnt23, say, is on
a filesystem on which no suid programs exist, you're safe.
-- 
Larry Campbell                             The Boston Software Works, Inc.
ARPA: campbell%maynard.uucp@harvard.ARPA   120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell     (617) 367-6846