chroot(2) security

[Jason Heirtzler]

In article <233 at BMS-AT.UUCP> stuart at BMS-AT.UUCP (Stuart D. Gathman) writes:
>In article <113 at nonvon.UUCP>, apn at 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 at bu-cs              Bitnet: csce1mc at bostonu
Uucp:  ...harvard!bu-cs!jdh   Arpa:   jdh at bu-cs.bu.edu