Reasons for restricting su privilege?
David Brown
I'm having a problem convincing some of the people around
here of the dangers of having several super users. One of
our faculty members insists upon having the privilege,
for whenever one of the normal super users isn't around. I've
tried every argument I know, all to no avail. Any hints?
Any new arguments? For that matter, give me the old arguments.
I'm not asking for detailed 'holes', all I want are valid reasons
for restricting the su privilege.
Also, just in case I lose this one, does anyone know of a 'restricted
super-user' program? One that just allows some things to be done.
I'm afraid I'll need to write one, and I don't want to 'reinvent the wheel'.
Might better e-mail me any responses; there is probably a LOT to say
on the issue. If there is interest, I'll post a summary.
Thanks,
David Brown
----------------------------------------------------------------------------
David Brown
Armstrong State College, Savannah, Georgia
uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!david
ARPA: da...@pyr.gatech.edu
Karl Kleinpaste
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.
The `old' reasons for not allowing general superuser access are
legion, but a couple of the better ones from a practical point of view
revolve around keeping track of who knows The Password (which is to
say, Whom can you readily accuse of malfeasance/stupidity?, and What
if someone tells It to someone else who shouldn't know?) and the
problem that "a little knowledge is a dangerous thing."
--Karl
Thad P Floryan
of David Brown's question about restricting super-user privileges, but it'd
seem good sense to me to have (at least) two trusted people at a site with
the capability of su'ing in case one person is ill, out of town, etc.
Re: a program executing "restricted super-user" commands, I recall "something"
named "sudo.c" in the archives that could be the basis for such restriction.
The restricted scope would be defined upon interrogation of a database, the
nature of the command(s), etc.
Thad Floryan [th...@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
Eirik Fuller
) 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.
Chris Calabrese[rs]
> In article <25...@tut.cis.ohio-state.edu> ka...@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes:
> ) Personally, I advocate a menu-driven setuid-root program which allows
>
> 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 did one of these menu things when I was in school. The way
I solved these types of problems was:
You could add, modify, and delete lines in /etc/passwd,
but only using the supplied menu based editor, and
only for users with uid and gid >= 100.
You could su to any account with uid and gid >= 100.
You could view any file.
You could remove and file in /etc (and mabee /bin but
I don't remember that part to well).
File viewing and removing operations were done with
internal code so there were no leaks from possible
security holes in more, pg, cat, rm, etc.
All in all it worked pretty well (though the code is pretty
hackish compared to what I can do now :-).
If anyone wants source I can get it, though I'll have to
retrieve it from tape.
--
--------
Christopher J. Calabrese
AT&T Bell Laboratories
ulysses!cjc
Karl Kleinpaste
) 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.
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,..."
I guess I can only say that account creation is not something that a
stopgap pseudoadmin would need or be allowed to do. The definition of
what a pseudoadmin needs to do would have to be decided by experience.
I don't agree with giving out the root password to more than a bare
minimal set.
--Karl
Barry Shein
> I'm having a problem convincing some of the people around
> here of the dangers of having several super users. One of
> our faculty members insists upon having the privilege,
> for whenever one of the normal super users isn't around. I've
> tried every argument I know, all to no avail. Any hints?
> Any new arguments? For that matter, give me the old arguments.
> I'm not asking for detailed 'holes', all I want are valid reasons
> for restricting the su privilege.
You're looking for a way to turn a technical bludgeon into a political
one, always a tricky bit of alchemy.
I generally wasn't too nervous about people with some technical
competence having privs on a multi-user system. Ultimately it's up to
the user community of the system (ie. the ones who might be adversely
affected), or whoever really should have the say, sounds like your
real problem is you haven't developed any authoritative way to settle
such an issue so you bicker. Perhaps if there was some such thing
they'd take away your privileges :-)
One thing I usually pointed out was that if you can't take the heat
you'd be better off staying out of the kitchen (coupled with trying to
understand why exactly the person believes s/he needs privs on the
system.) That is, if ya break something, you'll fix it. If you screw
someone else that fact will be pointed out in public (ie. to the user
and users affected), just as with anyone with such privs. There has to
be some accountability when one gives the keys to the asylum to the
inmates.
Sometimes all they really wanted was to be able to unf**k the printer
or some such which could usually be done with a setuid program I could
throw together. Sometimes it was just frustration that operations
folks weren't doing *their* job properly (ie. calling and asking for a
printer to be unf**d would draw a blank), so some training was in
order. Sometimes it was just an inability to accept that occasionally
things go awry and having privs is not some magic key to power over
computers, at least not in the wrong hands.
Sometimes they needed them and could be trusted with them so what the
heck, especially if it was their system anyhow and they were willing
to be accountable to their user community and the other admins. If not
then you're screwed, your political situation is untenable, they can
come into the lab, throw glassware and chemicals about, use expensive
equipment as field hockey pucks and you've got to clean up and get
things right again when they're finished and keep serious users of the
"lab" happy. Too bad, yer dead meat. On the other hand one has to be
somewhat sensitive to feelings of being treated like a child or an
idiot, throwing in the accountability with the privileges should
accomplish that, after all, that's all you're really trying to get
across (right?!)
"With rights come responsibilities"
-Barry Shein, ||Encore||
Barry Shein
subtle and mysterious things Unix systems (and any system for that
matter) can do to you. Part of the trick is having habits which
restrict oneself to tried and true software (eg. bare commands rather
than whipped together shell scripts...note, no relation to suid shell
scripts.)
I think it was 4.2 (maybe all of them) that would *always* test:
if(-x filename)
true if you were root and the file existed, regardless of its being
+x, for example. Strange and mysterious (see, we had a script which
allowed "user-friendly" access to chmod, you could say "setpriv public
files..." or "setpriv private files...", and it would, among other
things, attempt to see if the execute bit should be propagated, acted
real strange under a root account til I figured the above out.) No
flames about csh scripts etc, that's always nice advice, but misses
the point entirely.
Software running under root accounts can also inadvertently break
critical locks in the file system etc (eg. when they depend on failure
returns to honor simple-minded locking schemes, and root won't fail in
those cases, which is a feature, but not for such software.)
Then again, most sysadmins who must have root access probably have
only the vaguest idea about what I'm alluding to, or what software
might be affected.
Ah, fraught with danger, refreshing...
-Barry Shein, ||Encore||
Snoopy T. Beagle
|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.
Before lunch? Try "in a matter of seconds". UTek's sysadmin was not
designed to allow doing selected root-ish things without allowing a root
shell, it was meant to hold the hand of a non-wizard root who needs to
install a new software package or whatever.
|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.
For the non-wizard types, something like sysadmin can be helpful. For
most of the readers of this newsgroup, it is slow, and gets in your way.
(in fact, I've been wanting to free up some disk space, hmmmm...)
If you want to limit what they can do, you'll need to look elsewhere.
Disclaimer: I *used* to work for Tektronix, in the UTek group.
For all I know they could be hard at work changing
the charter of what sysadmin does.
_____
/_____\ Snoopy
/_______\
|___| tektronix!tekecs!sopwith!snoopy
|___| sun!nosun!illian!sopwith!snoopy
Linda Birmingham
>
>> I'm having a problem convincing some of the people around
>> here of the dangers of having several super users. One of
>> our faculty members insists upon having the privilege,
>> for whenever one of the normal super users isn't around. I've
>> tried every argument I know, all to no avail. Any hints?
>> Any new arguments? For that matter, give me the old arguments.
>
early this year. sush is a restricted shell that allows systems
administrators to grant specific limited privileges to users.
All commands that are executed are logged to the system log, as
well as other pertinent information.
I feel strongly that the number of super-users should be limited. It's
hard to trace any "funnys" on the system when a number of people have
had their fingers in the pie. We all have bad days. We all make mistakes.
the more super-users you have the more inconsistencies you are going to
get. The more super-users you have the greater the possibility of a terminal
being accidentally left in root mode, and the greater the possibility of
the password being observed.
However, if you are strict about the number of super-users you should always
make sure one of them IS available or at least can be contacted if possible.
>"lab" happy. Too bad, yer dead meat. On the other hand one has to be
>somewhat sensitive to feelings of being treated like a child or an
>idiot, throwing in the accountability with the privileges should
>accomplish that, after all, that's all you're really trying to get
>across (right?!)
Providing you can prove WHO screwed up the system !!
Linda.
--
Brunel University, Uxbridge, Middlesex, England.
janet: li...@uk.ac.brunel.cc | :-)
uucp:...ukc!cc.brunel!linda |
der Mouse
> In article <39...@encore.UUCP> bzs@xenna (Barry Shein) writes:
>>> I'm having a problem convincing some of the people around here of
>>> the dangers of having several super users. One of our faculty
>>> members insists upon having the privilege, for whenever one of the
>>> normal super users isn't around.
Why not grant it? Are you that certain this person is not competent to
handle the privilege? Remember, you're there to serve your user
community, of which this person is presumably a part. (If not, then
why pay any attention at all?)
Not that this necessarily has any bearing on your situation; you'll
have to be the judge of that.
der Mouse
old: mcgill-vision!mouse
new: mo...@larry.mcrcim.mcgill.edu
Bob Deroy
>In article <4...@Terra.cc.brunel.ac.uk>, li...@cc.brunel.ac.uk (Linda Birmingham) writes:
>> In article <39...@encore.UUCP> bzs@xenna (Barry Shein) writes:
>>> (an attribution line seems to be missing here)
>>>> I'm having a problem convincing some of the people around here of
>>>> the dangers of having several super users. One of our faculty
>>>> members insists upon having the privilege, for whenever one of the
>>>> normal super users isn't around.
>
>Why not grant it? Are you that certain this person is not competent to
>handle the privilege?
I have to agree with Barry. I don't think it is so much a matter of
competence but of keeping track who's doing what. I have seen my share
of "who changed $@$^% without telling anyone". Then there always "how
come he has su but I can't". Just think it is easier and creates less
problems with as few super users as you can get away with.
UUCP: ...!harvard!bu-cs!bu-it!rwd INTERNET: r...@bu-it.bu.edu
CSNET: rwd%bu-it@bu-cs BITNET: engbd3c@buacca
--
UUCP: ...!harvard!bu-cs!bu-it!rwd INTERNET: r...@bu-it.bu.edu
CSNET: rwd%bu-it@bu-cs BITNET: engbd3c@buacca