A bunch of people seem to be reposting of the VMware KB article on adding a second superuser (root) account to VMware ESX. I have to ask:
Why would you ever want a second superuser account? Isn’t one enough trouble?
Root is basically a user with full access to the machine. And by “full” I mean “uncontrolled and unaudited.” When it comes to securing a computing environment I don’t usually want to add more accounts like this. I usually want to reduce them, and secure any accounts like that which absolutely need to remain.
My recommendation, in all cases, is to secure your root accounts well with SSH restrictions (which is the default in ESX), firewalling, and very secure passwords. If others need access to the host add an account for them, and if those people need root-level privileges for something look into how to configure sudo so that they can run just the commands they need as root.
The comments over at Leo’s Ramblings have a small discussion about how this is a bad idea, and to Leo’s credit he concurs, acknowledging that sometimes the only fix for a problem is a bad idea. In general, though, the whole “add another root account” idea goes in my category of “just because you can doesn’t mean you should.”
I agree “just because you can doesn’t mean you should.” However, like Leo says, sometimes the only fix, is a bad idea.
-Cody
http://professionalvmware.com
Would it be a bad idea to make a second Super User account like this, and Disable to root account? Wouldn’t it be a better practice than allowing Root to be active, from a security side of things? Since every ESX / ESXi box has a root account, someone trying to get / gain access would try that account first in a event they gain access to the network.
Let me know your thoughts.
Roger L
Once, many many moons ago, probably near the peak of my danger curve, I got tired of su’ing all the time, so I just changed my uid to 0 in the passwd file. That was fun.
Laughing @ Matt S.
I know… doesn’t contribute much to the discussion, but I had to acknowledge the humor.
Roger is correct above. The reason you want a second root account is so that you can disable “root” but not lose the ability to have a user with the same privs. Attackers now have to know the super user’s username and password, rather than just the password.
Simply put, the reason for a second root account for security.
Thing is, it all seems pretty much like “security through obscurity” to me. If your security relies on someone not knowing that ‘root’ is now called ‘fakeout66’ it’s pretty weak. Someday someone will dump /etc/passwd through a compromised app and your security will be right back where it was.
Just to let you know, what you name your uid 0 account doesn’t really matter from a security perspective.
If you were a blackhat all you want is effective uid 0.
Creating a second uid 0 account or renaming the original uid 0 account absolutely adds nothing to security! It does not even add any obscurity, as most unix security exploit don’t care about the name service switch or any other built-in name resolution functions. uid 0 stays superuser whatever you do.
secure the passwords, clamp down your networks, patch your systems.
Cheers.
Those who would prefer to SSH directly in as root have not yet been burned by the consequences of doing so.
Since ESX 3.0 secured against root SSH logins, I’ve always created an shell-enabled login and su’d as required. su, UAC, and the like are all really annoying until you’ve accidentally done something you can’t undo.
@Christoph: Amen.
@Alex: Also agreed. At least when I do something stupid via sudo I can figure out what I did afterwards. Usually it’s running something as root that should have been running as another user (and screwing up permissions as a result), but sometimes I’m less lucky.
I’m certainly not advocating the use of a second account…I don’t even use the first root account. sudo eliminates my need to su/login as root, however, the reason you would want to have a second super user, in my opinion, is stated above.
We also hit the problem of having lots of cooks in the kitchen and no accountability.
We solved this by creating an LDAP group called “ESX Admins” and then putting all the cooks in this group. We then gave this group Administrator rights to the whole ESX cluster.
There are loop holes in this scheme, people could just point their VIC client directly at a host, but in general they don’t. Thus when someone brings down a host or adds storage it’s logged.