david@pyr.gatech.EDU (David Brown) (10/19/88)
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: david@pyr.gatech.edu
karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) (10/19/88)
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. 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@cup.portal.com (Thad P Floryan) (10/20/88)
I'm still a "new" SysAdmin so haven't yet formulated policy along the lines 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 [thad@cup.portal.com (OR) ...!sun!portal!cup.portal.com!thad]
eirik@tekcrl.TEK.COM (Eirik Fuller) (10/21/88)
In article <25003@tut.cis.ohio-state.edu> karl@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.
cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs]) (10/21/88)
In article <3185@tekcrl.CRL.TEK.COM>, eirik@tekcrl.TEK.COM (Eirik Fuller) writes: > In article <25003@tut.cis.ohio-state.edu> karl@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@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (10/21/88)
eirik@tekcrl.TEK.COM (Eirik Fuller) 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.
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
bzs@xenna (Barry Shein) (10/23/88)
> 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||
bzs@xenna (Barry Shein) (10/23/88)
Although most anyone using a root account is subject to it there are 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@sopwith.UUCP (Snoopy T. Beagle) (11/01/88)
In article <3185@tekcrl.CRL.TEK.COM> eirik@tekcrl.TEK.COM (Eirik Fuller) writes: |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@cc.brunel.ac.uk (Linda Birmingham) (11/08/88)
In article <3948@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. I've >> tried every argument I know, all to no avail. Any hints? >> Any new arguments? For that matter, give me the old arguments. > Try getting hold of the super-user shell which was on the net 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: linda@uk.ac.brunel.cc | :-) uucp:...ukc!cc.brunel!linda |
mouse@mcgill-vision.UUCP (der Mouse) (12/02/88)
In article <479@Terra.cc.brunel.ac.uk>, linda@cc.brunel.ac.uk (Linda Birmingham) writes: > In article <3948@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? 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: mouse@larry.mcrcim.mcgill.edu
rwd@bu-cs.BU.EDU (Bob Deroy) (12/03/88)
In article <1371@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <479@Terra.cc.brunel.ac.uk>, linda@cc.brunel.ac.uk (Linda Birmingham) writes: >> In article <3948@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: rwd@bu-it.bu.edu CSNET: rwd%bu-it@bu-cs BITNET: engbd3c@buacca -- UUCP: ...!harvard!bu-cs!bu-it!rwd INTERNET: rwd@bu-it.bu.edu CSNET: rwd%bu-it@bu-cs BITNET: engbd3c@buacca