Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!rutgers!husc6!bu-cs!jdh
From: jdh@bu-cs.BU.EDU (Jason Heirtzler)
Newsgroups: net.unix-wizards
Subject: Re: chroot(2) security
Message-ID: <1669@bucsd.bu-cs.BU.EDU>
Date: Fri, 3-Oct-86 22:25:37 EDT
Article-I.D.: bucsd.1669
Posted: Fri Oct  3 22:25:37 1986
Date-Received: Sat, 4-Oct-86 12:53:23 EDT
References: <158@itcatl.UUCP> <113@nonvon.UUCP> <233@BMS-AT.UUCP>
Reply-To: jdh@bucsd.UUCP (Jason Heirtzler)
Organization: Boston University Distributed Systems Group
Lines: 43
Summary: chroot(2) is best left as it is

In article <233@BMS-AT.UUCP> stuart@BMS-AT.UUCP (Stuart D. Gathman) writes:
>In article <113@nonvon.UUCP>, apn@nonvon.UUCP (apn) writes:
>
>> 	write a program that changes the root directory to /mnt23/user/test
>> 	and then procedes to exec /bin/login
>
>	On our system, login only has execute permission for root.
>But, one can link in the 'su' command! Even if the /bin directory is
>execute only!  The resulting superuser process could then *modify* the
>su program to allow a special root password after leaving the chroot process.
>(Otherwise, even the root process could not access anything below the new
>root directory.)
>
>I believe that 'su' is the only problem.  Take away 'su' and you can give
>them 'chroot'.  ('newgrp' is similar but not as bad.)
>-- 
>Stuart D. Gathman	<..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>

"Taking away" su(1) really won't help the problem at all.
Note that on other Unix systems (BSD 4.2 and SUN 3.0 for instance),
/bin/login is executable by everyone.

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.. or the exact same thing could be
done for /bin/su in place of /bin/login. You'd probably need other stuff
like a link to /bin/csh and maybe a link to / (to get out of the whole
mess, yourself). You get the idea.

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.


---------
Jason Heirtzler

Csnet: jdh@bu-cs              Bitnet: csce1mc@bostonu
Uucp:  ...harvard!bu-cs!jdh   Arpa:   jdh@bu-cs.bu.edu