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?
You should have one big global sudoers file which is able to get preprocessed by cpp or m4. Then simply output the preprocessed file on a per-server basis.
You can even use sudo's built-in mechanism between differentiating hosts.
You will get very fine-grained control, as different people will have different access through just running the preprocessor.
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 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...
sudoscript preserves your audit trail in root shells. It's not perfect, (there are still ways to evade the auditing) but if your concern is to have a record of root's actions so that problem diagnoses is easier, rather than keeping malicious users from doing bad stuff, then it's useful.
"Even if you are on the right track, you'll get run over if you just sit there" - Will Rogers
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.
- Make sure that only root can execute the su command.
- Distribute access to the su command via sudo, and only allow specific syntax for loading roots
.profile - In roots profile, establish a separate history file for each original user, and a log which shows where they are connected from, and whatever else you need separated by human user
The drawback is that most users cannot su to a non root account, but they can still ssh user@localhost. This is by no means a particularly robust solution, but it is better than having the root account shared completely IMHOI find the best way to distribute root access is not to use passwords at all.
.ssh/authorized_keys file automatically, then removing someone's access or granting access to someone is a simple matter of running the script across all the systems.
Disable the root password (or set it to something nobody knows), and only allow access via ssh's public/private key system. If you have a script which will set up the
This way nobody has to remember a password(s), you don't have to worry about cycling passwords, and if someone leaves you can remove all their access in minutes.
We have a policy of requiring all ssh private keys to have a passphrase of a reasonable length, so people can't go using other people's keys.
Anything is possible, except skiing through revolving doors.
When I worked at UnixOps we had several different versions of
Michael.
Linux : Mac
If you use "root", someday you will be rooted.
This may not scale well to your 300 servers, but I saw it used effectively for 20-30 servers at one company I worked for.
The basic idea is to use a locked box to store the passwords in. The box is secured with a simple padlock, to which every knows the combination. For each machine you want to manage the password for, you have an envelope in the box with that machine's name on it in the box, along with a bunch of empty envelopes and some blank password sheets which I'll describe later.
So, you're setting up a new server, say, "fred". You take a blank password sheet and fresh envelope out of the lockbox. The password sheet is basically a simple table with password, name, date, and reason columns on it. Write "fred" at the top of the password form, and then fill in the first line with the root password you've just chosen, your name, today's date, and the reason for the password change, in this case "new machine setup". Fold up the password sheet, put it in the envelope and write "fred" on the front of the envelope. Seal the envelope, and then write your name and the date across the seal. Put the now-sealed envelope in the lockbox and lock the padlock back in place.
Ok, that was quite a bit of work. So, what's it do for you? Suppose you need to do some administration on fred, and you've either forgotten or never knew its root password. You go to the lockbox, open it up (remember, everybody knows the padlock combination), and find the envelope labelled "fred". Now, look at the back of the envelope. Is it unsealed, or does it look like the signature/date over the seal has been disturbed in any way? If so, you might want to change the root password before you're done.
Assuming the date and signature on the seal looks good, open the envelope and pull out the password form. The current password is the last line. Fill out the next line with the same password, you name, the date, and some reason like "forgot password". Throw away the old envelope, take a new one from the box, refold the password form and seal it in the new envelope. Write "fred" on the front of the envelope, and sign and date the seal on the back. Now you know the password.
Now, what do you do if you actually want to change the root password for some reason? It's pretty much the same as above. Find the envelope for the system, and open it to find out the current password (if you don't already know it). Make a new password table entry, and seal a new envelope as described above, and put it back in the lockbox. Note that you can do this at any time, and your fellow admins can still find out the new password without any help from you.
This approach assumes a relatively low rate of password change, and that administrators have physical access to the lockbox most of the time. It also assumes that you want per-machine root passwords. In addition, it allows admins to memorize passwords for machines they use relatively frequently without having to write down passwords for machines they use rarely.