Q: At a site with multiple sysadmins, should all of them use one root account or should they each have their own?
A: It's definitely better to give each sysadmin separate accounts. You might make these root-level accounts by setting their user IDs to 0. Or you could leave them unprivileged, so sysadmins would have to use the "su" command to gain privilege. Using su means that anyone who compromises a sysadmin account would need both the admin's login password and the root password to get root. In either case, you gain increased audit capability and the ability to contain an account compromise.
Separate accounts make it easier to detect account thefts by providing a clearer picture of who is logging in when. Suppose Rob is on vacation. A login from his account should raise a yellow flag. If Rob's account has been stolen, you can deactivate it without locking all your sysadmins out until you issue them new passwords.
In addition, by using SSH's AllowUser directive, you can limit which IP addresses each account connects from. This is even more granular than firewall rule sets, since you can set restrictions on an account-by-account basis.
Lest you think your admins' passwords can't be compromised, let me assure you, as a professional pen tester, that even sysadmins end up with brute-forcible passwords. They might use strong passwords, but use the same password for their administrative account as they use for their e-mail or for their Telnet-administered routers. Worse, their site may use Network Information Services (NIS), which grants a copy of an encrypted password to anyone on the LAN.
Another way to control and protect admin access is the free tool Sudo. Instead of logging in with a root account, or "su-ing" to root, each sysadmin logs in as an unprivileged user. Sudo requires the admin's password for each command that's executed with root privilege. As a practical matter, if a Sudo command has been run in the last five minutes, a password isn't required. This time window balances convenience with security. Sysadmins don't always lock their console when they walk away, but the time limit makes a compromise less likely.
Sudo also provides you excellent audit capability, logging every command that was run as root for the account that ran it. Alternatively, you may want to investigate a commercial product like Symark's PowerBroker, which also provides granular control of admin access for *nix systems.
Tools like Sudo and PowerBroker allow the same containment functionality as with separate privileged sysadmin accounts. If a sysadmin account is compromised, just deactivate it and issue a new one.
Further, by allowing you to assign such granular privilege -- by command -- Sudo reduces the impact of a stolen account. Suppose that you have a staff member who is only given root privilege to run backups. An attacker stealing this user's account only gains the ability to run backups, instead of full root privilege.
Actually, I recommend disabling the su command entirely when you're using Sudo. Think about how most of us use su. You su up to root, stay there for some time, and then back out to normal user status. In practice, admins often run many programs with unnecessarily high privilege rather than taking the time to frequently exit and restart the su session. Remember that a vulnerable program can only grant an attacker the privilege that it is run with. For example, a vulnerability in the "man" command, like the one in Red Hat 6.0, gives an attacker root privilege only if run by a root user.
The nice thing about Sudo is that sysadmins tend to run far fewer programs as root, since they have to expend additional effort for each command they run. It's a different model, in which keystroke-saving actually enhances security instead of decreasing it. The lone disadvantage of Sudo compared with su is that it requires only a single password.
About the author:
Jay Beale is the lead developer of the Bastille Linux project, which creates a hardening script for five Linux distributions, HP-UX and Mac OS X.