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?

Comments

Public Keys, ACLs, and sudo

[imsmith]

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.

What about key-based SSH authentication?

[DocSnyder]

Every admin can generate his SSH key pair and have the public key appended to /root/.ssh/authorized_keys. Maybe the private keys could be stored on a USB stick or a chip card for better security. They should be protected by key-specific passwords, too.

So nobody would get in touch with actual root passwords, which can be stored at a safe place.

Re:What about key-based SSH authentication?

[rimu guy]

Of course even one hour's root access is enough to enable the user to add their own back doors (e.g. other user accounts). So you'd also need to monitor things like /etc/passwd and shadow file changes carefully. And tools like Chkrootkit can help.

But definitely, ssh public/private key authentication is the way to go.

- Linux VPS Hosting

I'd use PAM

[Anonymous Coward]

PAM, Pluggable-Authentication Modules. The PAM Radius module, with a central radius server, has worked for me in my testing, but I wish the module was a little more featureful in doing something with return attributes. It's one of those things I kept wanted to do, never had time for. A random descriptive page I found is here One minor caveat: it's moderately easy to misconfigure PAM to allow too much access - just be careful and use a standardized configuration.

Auditing..

[RedPhoenix]

You may want to consider establishing a basic auditing policy, to back up any access controls you put in place.

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, /dev/audit for AIX, Irix, Unicos, etc.).

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.

Re:dealing with this as well...

[Brandybuck]

Give _everyone_ root access.

What! You've got to be kidding me! Unless you're also requiring them to also fully administer their machines, this is one of the lamest ideas I've seen in months.

Just because they're developers doesn't mean they're smart, competent or even computer savvy. It certainly doesn't mean that they're trustworthy.

Re:ssh private keys

[hbo]

The problem with this is single-user mode. Even though there are various tricks to get console root on various flavors of Unix, in a large organization, you can bet that a sysadmin that doesn't know the particular trick for the OS in consideration will have to go in to single-user to fix something. The consequences of this could range from annoying (3:30 AM: "Hi, Mr Senior Sysadmin Guy. How do you get root on xyz?") to fairly painful, like having a revenue-critical database server down 45 minutes longer than necessary.

Re:Sudo and CVS

[Elwood P Dowd]

Ok, ok. You convinced me. A workaround is needed:

sudo wget http://ftp.gnu.org/gnu/bash/bash-2.05b.tar.gz
sud o tar zxf bash-2.05b.tar.gz
cd bash-2.05b
sudo configure;make;./bash

Here's a hint: If you are a trusted user, then you can create a process that will do all the things you desire without logging. You could patch the OS and log system calls, but they could patch the OS and fix your logs.

If you do not trust a user, then do not make them a trusted user. Leastaways don't make them a trusted user on the machine that is supposedly logging their actions.

Re:Sudo and CVS

[phaze3000]

Except that with sudo access anyone with sudo access could easily get hold of /etc/shadow and then crack the root password. Create a shell script with an innocuous sounding name which grabs /etc/shadow, run it via sudo - all you're going to see is the user with sudo access has run a script.

I'd therefore recommend you change the actual root password when anyone who had sudo access leaves.