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 just made them a root-user which was typically nick-root, that way things could be more easily tracked, etc. Works pretty well.
I would expect such blatant racism on Fark, but on Slashdot? Mods please ban this asshole.
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 a perfect world, Kerberos is the way to go. Your kerberos ticket would, according to the access controls on each box, grant login and root privileges. SSH can pass along your ticket, granting you seamless access with your credentials.
In practice, Kerberos is really hard to do right and so far ssh support is very weak. But if everything was kerberized (this is in the works), then everything from logins to web access can go through your ticket. Granting root privileges is merely a matter of setting the acl properly and then letting the use ksudo.
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
You may want to consider establishing a basic auditing policy, to back up any access controls you put in place.
/dev/audit for AIX, Irix, Unicos, etc.).
Depending on what operating system you are using, you could turn on execve / set*id auditing. This functionality is available in a variety of unix implementations (BSM for Solaris, Snare for Linux,
Alternatively, many OSs provide 'sulog' or equivalent.
Note though, that auditing root suers is an inherently risky process, as a root user can cover their tracks quite easily by removing audit log data; as such, you might want to consider real-time forwarding of audit data to a central server, getting it off the host machine, and away from the administrative influence of the root-level user. For basic log files, this is effectively a tail -f | send across the network. For OS-level auditing, it's generally a little more complex.
Red.
That's easy: With Post-it notes on monitor bezels.
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.
The wheel group is the traditional UNIX way of restricting root access to a privledged few.
/etc/suauth---it's in the man page.
It's not this way with GNU su, because RMS don't like it that way (too totalitarian, etc...).
You can make GNU su act like normal su by adding a line in
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
> "How would you distribute root over hundreds of Unix machines to the administrators that need it?"
/etc/ssh/authorized_keys/{login} using an access control list that we distribute to every box. The control file is centrally managed (kept in CVS) and has groupings for roles, individuals and servers, so administration is a breeze. The generator is just a short perl script. Finally, we have these lines in /etc/ssh/sshd_config:
/etc/ssh/authorized_keys/%u
:)
We have a similar team size and a similar number of servers. In addition there are other teams with access to more limited (regular user) team role logins. Access also varies according to server role and location.
These systems are often located in continents away in untrusted locations. So passwords are not acceptable.
My solution:
We have a standard Debian package that updates
AuthorizedKeysFile
PermitRootLogin without-password
We make a contingency for emergencies, but I won't describe it here. Suffice to say that it's safe enough to use, analysed enough that it's not snake-oil, and inconvenient enough to stop sysadmins in a hurry from using it by default
- J