Slashdot Mirror
How Would You Distribute Root Access?
dhanks asks: "I'm one of 10 administrators in our group. We're equally responsible for about 300 UNIX servers. We're having problems keeping track of all the root passwords and some of the administrators have taken it upon themselves to implement different security standards. (sudo with silly !SHELLS restrictions) How do other companies and system administrators handle the distribution of root access? I've been charged with coming up with a security policy and I would like to receive some feedback. I'm currently thinking of personal root accounts that would be locked via the /etc/passwd and would only be accessible via 'sudo su - adm_userid' that way each administrator may have full root access only using his regular user password instead of having to keep track of root passwords." While this is similar to an earlier question, this question deals with insuring authorized administrators have the access they need. How would you distribute root over hundreds of Unix machines to the administrators that need it?
I keep track of system changes on our linux servers using sudo and CVS. Admittedly, my situation is on a much smaller scale (2 admins, handful of systems). I like to use sudo because then any command that's run as root is traceable back to who did it via the system logs. (of course someone could hide their tracks by editing the logs...) I trust the other admin here, but in the past, I've set up sudo so that people could NOT USE the su command. The reason I did this is so that someone couldn't do a sudo su -, and then do whatever they want as root, unlogged. There are still workarounds, as sudo is not a be-all-end-all of security. You still need standard procedures, and you have to make sure people follow them.
As for the CVS side of things, I just keep a "sysconf" module for each server. Whenever I make any changes to a system file, I will first add it into CVS. Then all subsequent changes are made to the CVS version'd file, and notes and stuff committed to CVS. After committing to CVS, the admin then moves the file into the proper system location and does whatever else is neccessary to make the changes take effect. Once again, it doesn't work unless people use it. There's nothing I have in place that would keep someone from editing the file in the system location (since they need root to put the file into place...), but I try to discourage people from doing that.
Eventually I'd like to write some scripts and a DB backend that will hold the locations of all the files, so it's easier to move them into the proper location. But I haven't started that yet...
Place sig here.
In general, nobody should EVER type the root password, only their su$NAME password. That way, if it gets compromised (accidentally typed somewhere bad) you only have to change it in one place (NIS master) rather than on all machines.
All of this seems pretty obvious, so let me know if there's something unusual about your setup that makes this unworkable.
Novell Directory Service.
Oops, that's three words. Try "eDirectory" instead.
No, wait a second - I seem to recall that Novell marketing renamed it yet again - now it's called either Ngage, exteNd, Nsure, or Nterprise - not sure which.
Frankly, I'm not even sure the people at Novell know what it's called anymore.
Maybe we should moderate Redmond "+1 Has a Clue" simply for fielding a marketing team that knows its ass from a hole in the ground...
I'm a user dealing with this right now. Here's what I wish they'd implement at my place.
Give _everyone_ root access. These machines are behind a firewall, right? These are used by developers working to design/forward your company's projects right? If there's the slightest chance that they'll need root, give it to them.
Now, how do you deal with the chaos that results?
Simple. Write a script that reimages the drives on a regular basis. Daily, weekly, monthly, or even by command. In that way, you know the machines will always be kept up to date.
Use your existing admins to maintain and develope the image that you push down to the client machines. Every user should know that the machines will be reimaged often and that they can't plan on the machine always being in the same state. If they have an application or library that they want to persist, then have a procedure for having one of your admins add it to the master image.
User files should be kept on a file server elsewhere. Home directories may or may not be mounted to the machines as you like.
Everyone deserves root. Even those people that are going to screw the system up. (Once or twice, and they won't do it again.)
1. 2.
When I worked at UnixOps we had several different versions of
Michael.
Linux : Mac
If you use "root", someday you will be rooted.