jgarb@csd4330a.erim.org (Joe Garbarino) (06/04/91)
I'm sure this has been discussed to death in other groups, but I haven't seen it and this seemed to be an appropriate place. I am responsible for some 40 workstations. These workstations are all connected to the Internet, and are dispersed among 18 different groups, each of which would like to have root privileges on their machines. Is this a good/bad idea? What policies have various sites developed to deal with this question? If it's a bad idea, what are various methods for dealing with groups that demand they have root privilege? Any advice for sites on how to approach revoking privileges? -- Joe Garbarino -- ERIM jgarb@erim.org
gt1111a@prism.gatech.EDU (Vincent Fox) (06/05/91)
jgarb@csd4330a.erim.org (Joe Garbarino) writes: >I'm sure this has been discussed to death in other groups, but I >haven't seen it and this seemed to be an appropriate place. >I am responsible for some 40 workstations. These workstations are all >connected to the Internet, and are dispersed among 18 different >groups, each of which would like to have root privileges on their >machines. >Is this a good/bad idea? What policies have various sites developed >to deal with this question? If it's a bad idea, what are various >methods for dealing with groups that demand they have root privilege? >Any advice for sites on how to approach revoking privileges? I have yet to see any valid reason for my users to have root. The usual claims of "we need it so we can install our own software, etc" are rarely true. Particulary if your are running all these machines on NIS, it's better if only you have root. My rule is : If you want to be on my NIS, and have me make sure your machine is secured and runs reliably, I'm in the driver's set. The software installation issue I handle several ways. If it's just one product for one guy, why install it as root? Just load it into his home directory, for which root privs are rarely needed. If it's something that does need to be shared, they can schedule a time for me to drop by and do it. (Usually delaying things by 1-2 days for them, but saving them lots of time. Installing things like E-CAD can be tricky and require many calls to manufacturer for novices) The new automount facilities kill the problem of needing root to do mounts. And other programs COULD be setuid'ed as needed. -- Vincent Fox (That's Mr. Bucko to you)|Georgia Tech, the only place where Friday Georgia Tech, Atlanta GA |is only two working days away from Monday. SR-71: gt1111a@prism.gatech.edu | -- Uttered by David Sonnier during Pony Express:...!gatech!prism!gt1111a| CS3602 lab 5/10/1991 ~ 1730 EDT
doug@jhunix.HCF.JHU.EDU (Douglas W O'neal) (06/05/91)
In article <jgarb@csd4330a.erim.org (Joe Garbarino) writes:
->I'm sure this has been discussed to death in other groups, but I
->haven't seen it and this seemed to be an appropriate place.
->
->I am responsible for some 40 workstations. These workstations are all
->connected to the Internet, and are dispersed among 18 different
->groups, each of which would like to have root privileges on their
->machines.
->
->Is this a good/bad idea? What policies have various sites developed
->to deal with this question? If it's a bad idea, what are various
->methods for dealing with groups that demand they have root privilege?
->Any advice for sites on how to approach revoking privileges?
I am in a similar situation here. In each department, one contact has the
root password, but they do not use the root account except when something
goes wrong (printer stalls, machine crashes, etc.) AND I am not available.
This means there might be some delay in services occasionally, but hopefully
the machine is administered correctly and consistently.
There is one exception to the rule of the departments not messing with root (a
department that I cannot forbid messing with the system :( ) has given
be more grief that all the other departments combined.
My advice: let the departments know that you want to restrict root access as
much as possible. Then change the passwords and give a copy of the password
in a sealed envelope to one contact in the department. If they need to use
it, have them let you know afterwards.
Doug
--
Doug O'Neal, Distributed Systems Programmer, Johns Hopkins University
doug@jhuvms.bitnet, doug@jhuvms.hcf.jhu.edu, mimsy!aplcen!jhunix!doug
Like many of the features of UNIX, UUCP appears theoretically
unworkable... - DEC Professional, April 1990sarima@tdatirv.UUCP (Stanley Friesen) (06/06/91)
In article <30593@hydra.gatech.EDU> gt1111a@prism.gatech.EDU (Vincent Fox) writes: >The new automount facilities kill the problem of needing root to do mounts. >And other programs COULD be setuid'ed as needed. Only if what I need mounted is in the automount lists. On several occasions I have needed to mount a file system that was *not* in any of the officially maintained automount lists. Would you consider arranging to mount a file system to be another SA service like installing a software package? -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
jona@iscp.Bellcore.COM (Jon Alperin) (06/06/91)
You don't say wether these are user workstations, or multi user servers you are supporting. In our environment, we set up one password for our system administrators, and create special root privledge logins for those users with a demonstrated need for root access. We then inform these people that the machines will not receive "normal" support. If they kill the OS, all we will do is re-load it from our "golden" copy. they need to back up their own systems. This has seemed to discourage all but the most needy from requesting root access. -- Jon Alperin Bell Communications Research ---> Internet: jona@iscp.bellcore.com ---> Voicenet: (908) 699-8674 ---> UUNET: uunet!bcr!jona * All opinions and stupid questions are my own *
gt1111a@prism.gatech.EDU (Vincent Fox) (06/06/91)
sarima@tdatirv.UUCP (Stanley Friesen) writes: >In article <30593@hydra.gatech.EDU> gt1111a@prism.gatech.EDU (Vincent Fox) writes: >>The new automount facilities kill the problem of needing root to do mounts. >>And other programs COULD be setuid'ed as needed. >Only if what I need mounted is in the automount lists. >On several occasions I have needed to mount a file system that was *not* >in any of the officially maintained automount lists. What I do is have a entry in my NIS map for /net with keyword hosts. What this says is that any reference to /net/hostname/dir is an attempt to mount and access directory dir from hostname. If the remote host has it's /etc/exports files set to allow your machine access, I don't see any real danger here. I sometimes leave an optical in the NeXT with X and GNU source code, exported to all the world. Then if I'm somewhere I need to get it, I just do cd /net/cadnext2/storage. In short I maintain a list for /home controlled only by me. But /net is free-form. >Would you consider arranging to mount a file system to be another SA service >like installing a software package? In a sense. Before automount, and when the villagers had root, they tended to mount all kinds of things the permanent way in fstab. Then when any one of these many remote machines went splat, so did theirs. Since automounts disengage after 5 minutes of non-use, if that remote machine goes down in the middle of the night and it's not mounted to you, when you come in next morning your station won't be hung. It may stall a minute or so before timing out when you type cd /net/fred/wilma, but it won't hang. The remote machine can still screw you by going down while you are still mounted off it, but let's be honest, even home directories for most machines in a distributed lab environment aren't continuously active very much of the 24 hours in a day. Automount makes things more fault-tolerant, let's say. In other words, static mounts I use as little as possible and don't let anyone else have root to do them. But automount lets them do their thing without me now. I prefer to stay in my castle but placate the villagers with a tax cut and a color TV :-) -- Vincent Fox (That's Mr. Bucko to you)|Georgia Tech, the only place where Friday Georgia Tech, Atlanta GA |is only two working days away from Monday. SR-71: gt1111a@prism.gatech.edu | -- Uttered by David Sonnier during Pony Express:...!gatech!prism!gt1111a| CS3602 lab 5/10/1991 ~ 1730 EDT
russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) (06/07/91)
In article <jgarb@csd4330a.erim.org (Joe Garbarino) writes:
->I'm sure this has been discussed to death in other groups, but I
->haven't seen it and this seemed to be an appropriate place.
->
->I am responsible for some 40 workstations. These workstations are all
->connected to the Internet, and are dispersed among 18 different
->groups, each of which would like to have root privileges on their
->machines.
->
->Is this a good/bad idea? What policies have various sites developed
->to deal with this question? If it's a bad idea, what are various
->methods for dealing with groups that demand they have root privilege?
->Any advice for sites on how to approach revoking privileges?
You could consider something like the sudo program from 'unix system admin
handbook' by Nemeth, Snyder and Seebass. It allow you to give some users
the ability to execute a restricted set of commands as root. It also logs
anything it does. (So if they do stuff things up then at least you know
what they did.) This way you can let someone local have access the spool
control program and mount but nothing else.
Russell.
--
Russell Fulton, Computer Center, University of Auckland, New Zealand.
<rj_fulton@aukuni.ac.nz>jb3o+@andrew.cmu.edu (Jon Allen Boone) (06/07/91)
doug@jhunix.HCF.JHU.EDU (Douglas W O'neal) writes: > In article <jgarb@csd4330a.erim.org (Joe Garbarino) writes: > ->I'm sure this has been discussed to death in other groups, but I > ->haven't seen it and this seemed to be an appropriate place. > -> > ->I am responsible for some 40 workstations. These workstations are all > ->connected to the Internet, and are dispersed among 18 different > ->groups, each of which would like to have root privileges on their > ->machines. > -> > ->Is this a good/bad idea? What policies have various sites developed > ->to deal with this question? If it's a bad idea, what are various > ->methods for dealing with groups that demand they have root privilege? > ->Any advice for sites on how to approach revoking privileges? > You should find a person in each department and get to know her/him. S/he should be shown around the system, dicussing the various administrative policies along the way, as well as how to fix various problems. Then you should demonstrate how to boot the machine to single-user mode (something they may or may not already know, but will eventually find out!), if they forget the passwd. Then tell them that in the case of a problem, they should report it to you - if you are not available or are too busy to help them, you will authorize them to fix the problem. Most people are probably too busy in a day to day situation, to have to worry about constantly fixing every little thing that is broken - so make sure you pick (if you get to pick) someone who isn't TOO busy, but doesn't just sit around all day and do nothing. ----------------------------------|++++++++++++++++++++++++++++++++++++++++ | "He divines remedies against injuries; | "Words are drugs." | | he knows how to turn serious accidents | -Antero Alli | | to his own advantage; whatever does not | | | kill him makes him stronger." | "Culture is for bacteria." | | - Friedrich Nietzsche | - Christopher Hyatt | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
johnr@lotus.lotus.com (John Rouillard) (06/14/91)
What about using sudo. Sudo invoking a shell script to do the mount will work very nicely. The shell script should only allows mounting/unmounting to a known location so people can't play games by mounting their bin to /bin. Of course, hard wire all path names in the shell script and set the PATH explicitly so it is tougher to exploit holes in the shell scripts. -- John