One password to rule them all — aside from the fun Tolkienesque overtones, sharing a root password among admin staff to perform system administration is just a bad idea. Like the One Ring, a single root password can lead to serious problems.
Instead of provoking the wrath of Sauron, sharing a root password can lead to all sorts of mischief, mayhem, and lost productivity.
Malicious Users
The nightmare scenario, though the least common, is the rogue employee that abuses root privileges. It doesn’t happen often, but when it does the results can be fairly devastating. Take the story of Terry Childs, who locked up access to San Francisco’s FiberWAN network. Childs manage to cost the city quite a bit of money after resetting the administrative passwords for San Francisco’s switches and routers.
Consider the May 2005 CERT report on Computer System Sabotage (PDF), that tracked nearly 50 major incidents involving insider attacks between 1996 and 2002. Note these are only major incidents that affected “critical infrastructure,” and don’t include any “lesser” events that have happened at less sensitive organizations.
Not every insider attack is the result of having a shared root password, of course — but a shared administrative password is a potentially weak spot that no company should leave vulnerable.
Lossy Information
Most employees aren’t malicious, out to steal company data or inflict harm on company systems. But most employees do, eventually, leave or transition into new roles. Admins change root passwords and forget to update records. Any number of scenarios lead to finding that the root password for a system or systems is not, in fact, what the records say it should be.
This is another problem with sharing and using a root password for administration rather than some form of privileged user management. Yes, you can find workarounds to reset a root password, but that can be disruptive to operations — and usually entails taking a system offline. You don’t have to assume the worst about your employees to realize it’s a good idea to find a better solution to providing administrative access — just realize that they’re human, and that it’s entirely likely the system admins you have today are not the same team of admins you’ll have in six months.
Unlimited Access
There’s also the matter of the fact that some of the staff that need super-user privileges for one or two operations do not need — nor should have — access to all system privileges.
Maybe a one of the Web team needs to be able to restart Apache and MySQL — but there’s no reason they need full-on root access for the entire system. You may want the team to be able to restart Apache, but don’t want to allow them to install software. Maybe your DBA needs limited administrative access, but again — doesn’t need access to the whole system.
But even the admins who do need access to the whole enchilada need some accountability. Using the root password to perform system administration doesn’t fit the bill. While it’s usually possible to piece together who su‘ed to root, it’s more complex than it needs to be, and still leaves plenty of room for improvement.
Audits and Policy Compliance
Audits and policy compliance are a major reason to move away from the shared password plan. Whether you’re worried about Sarbanes-Oxley, HIPAA, PCI compliance, or any number of other regulatory or industry standards, demonstrating that you can account for access to system administrator accounts is crucial.
You also want to be able to audit access, and show who’s done what. Again, it is possible to piece together some information from system logs, it’s not a suitable substitute for real auditing capabilities.
Solutions
Once you’ve decided that sharing the root password is a bad idea, what’s the solution? That depends on your organization’s size, needs, and resources.
For smaller organizations, a solid sudo configuration may be enough. It should ensure that admins are using sudo to perform their duties, and have no more permissions that needed. This means that just allowing “all” for admins is not a reasonable solution in many cases. (Especially since they could easily simply escalate to root and set the password…)
Another solution is privileged user management in the form of products like Novell’s Privileged User Manager, or solutions from Centrify, Likewise, Quocirca, and others. Which one is right? That depends a lot on the individual environment. One size does not fit all. The only rule that applies to any sized organization is that the days of sharing root passwords should be long over.
