July 28, 2014, 8:27 PM — If your job involves protecting the security of Unix servers, you need to know about and verify the various ways that people can exercise root (i.e., superuser) privilege. This is especially true of you find yourself inheriting the systems administrator role from other people. A quick check of a handful of issues can help you be sure your view of security on the
servers is realistic.
Who has root access?
If the answer is "nobody but you", that's a great starting point, but you should still change root's password periodically. In addition, you should store it in a safe place -- maybe a secure password tool such as Keepass, maybe in an actual safe. One of my bosses from decades ago had me write down the root passwords we used on our large Solaris network and put them in a safe that nearly no one had access to. In case I got run over by a back hoe, someone would be able to keep our servers up to snuff.
How do they have it?
Root access is possible even if you don't know root's password, so you shouldn't run off thinking you've closed off others' access to this privilege just because you changed the root password to "N01canGuessMe@all!". Check the /etc/sudoers file to see if root privileges have been granted through it. Individuals might be able to run specific commands as root or might be able to use the command "sudo su -" and simply assume root's identity. When they do this, of course, they will be prompted to enter a password but not root's -- their own.
Can they log in as root?
The worst thing about anyone being able to log in directly as root is that you then have no accountability for what these individuals' do when logged in as root. All you know is that someone logged in as root on Saturday night after 11 PM and maybe what they did -- or maybe not. Legitimate users should log in as themselves and switch user to root when they need to make changes to the system that they cannot do with their own privileges. If you have coworkers who help out administering your Unix systems and they perform only a limited set of tasks, you might give them just the necessary privileges. Maybe they can add or remove accounts or reboot the servers, but nothing else.
To prevent direct logins as root, set root's shell to /sbin/nologin in the /etc/passwd file. Verify that /sbin/nologin exists on your system as this might not work on all Unix systems. Verify this works before you log off. You should still be able to su to root.
Root's UID is 0
When looking into who has root access on a Unix system, don't forget the root privilege is associated with the UID 0. If you have another user set up on your system who also has his UID set to 0, that person will have root privileges when he or she logs in. Don't be fooled.
Who has access via the sudoers file?
The sudoers file has many options for granting access.
flickr / Peter Clark