chroot(2) security

[Marc W. Mengel]

>In article <113 at nonvon.UUCP>, apn at nonvon.UUCP (apn) writes:
>
>I believe that 'su' is the only problem.  Take away 'su' and you can give
>them 'chroot'.  ('newgrp' is similar but not as bad.)

Actually, you need to get rid of almost *every* setuid program on the
system; at least any one that exec's another program via an absolute
path name.  Let's say (hypothetically) that ps had a -s option that
sorted its listing by uid, and that to do that, it wrote its usual
output in /tmp, and ran sort on it.  Now create a new root, with a
/bin/sort that actually gives you a shell, rather than sorting a file.
Now you do a ps -s and get a shell.  Get the idea?  the holes are many,
and well hidden.

I'm not even sure that ones that don't exec another program are safe, that's
just the few I can think of.  Setuid programs are the classic place to find
security problems;  they are only as secure as their own logic, which often
assumes (and rightfully so) that "/" is the real filesystem root.  Giving
normal users chroot will make this assumption invalid, and you will probably
find security problems coming out of the woodwork for years to come if you
allow chroots with out careful thought.
-- 
 Marc Mengel
 ...!ihnp4!cuuxb!mwm