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?
First, create one super administrator from the 10 (sorta like Voltron).
Second, create one giant supercomputer cluster from the 300 machines.
Third, give your new super administrator root access (with their choice of password) on the new supercomputer.
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.
With that many systems, the only rational access control seems to be to be using public keys and SSH agent to deal with the logon issue. Once in the system, the only way to keep track of so many cooks in the kitchen is to have sudo running and logging sysadmin actions. Finally, if there are specific files or groups of files that need special attention, I'd probably use ACLs to control access. Another thing that seems like a pain in the ass until it saves you is RCS. Especially with so many admins, being able to roll back a config change quickly is a lifesaver.
So nobody would get in touch with actual root passwords, which can be stored at a safe place.
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...
...and ssh rsa authentication in authorized_keys of root's. peice of piss.
just all use the password 'secret' - nobody would ever think a root user could so dumb.
Join the Free Software Foundation
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.
Trying to "restrict" sudo access via ! commands is dumb - there are too many shell escapes, etc. At some point, you MUST trust your admins, so just give 'em sudo=ALL. Having said that, I would setup syslogging to a central loghosts, and have some sort of audit process so if someone does an "su root" or a "sudo csh" (or futzs with the syslog configuration), then you beat 'em over the head with a baseball bat! ;-)
Ohhhh ... you say can't do the later ... then you are basically screwed, since if you don't have management support for this, you'll never succeed unless all of your admins realize having logging/accountability/etc. of root-type actions is a darn good thing for everyone - those type of folks work hard to make SURE whatever they do is logged ... whereas there always seems to be at least one admin who thinks they are above this stuff - some eventually learn, some don't.
BTW, note the loghosts (plural) above ... you should have this allready in place for general security purposes ... and NO admin should have access to all of the loghost machines - i.e. this allows you to deal with renegade Sysadmins who cover try to cover their tracks ... or worse yet, someone who tries to "frame" another Sysadmin.
sudoscript was allready mentioned as a nice compliment to sudo, and the sudo tools are also handy for some auditing features.
Hulk SMASH Celiac Disease