Reasons for restricting su privilege?

Eirik Fuller eirik at tekcrl.TEK.COM
Fri Oct 21 04:40:42 AEST 1988


In article <25003 at tut.cis.ohio-state.edu> karl at dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes:
) Personally, I advocate a menu-driven setuid-root program which allows
) for exactly the set of things which a not-normally-administrator
) person might possibly have to do in order to stay alive while a real
) admin is unavailable.  Restrict it heavily and never give an editor
) escape for any reason.
) ...

Yeah, sure, but what if this spiffy menu contraption allows its luser
to make new accounts?  "Gee, maybe I'll make an account with uid 0,
and put /bin/csh as its shell, and leave the password off until
someone comes along and puts one in, and see what happens ..."

I'm thinking in particular of UTek's sysadmin as one example of a
menustrosity that one could grant access to for fake superusers.  It
may not be what you had in mind, but my general point, if there is one,
is that your menu thing is likely to be either too limited to be useful
or general enough that someone who knows Unix will have himself a root
shell before lunch.

A program that carefully selects out what can be done "safely" might be
ok.  My offhand guess is that it would be far simpler, and more useful,
to single out existing commands with no escapes, and put 4754 0/0
permissions on them, or similarly adjust group permissions on the data
files they use if that is a feasible way of making them accessible to
mortals.  A menu-type thingy would have to be flexible to be useful;
"Hey George, we want to do lprm too; recompile weenie_root for me,
would you?" :-)

Enough already.  It really is easier to give out the root password;
on "modern" systems it can be disabled for a user by removing him
from group 0.



More information about the Comp.unix.wizards mailing list