Controlling Root User Access

System administrators know the power of the root user account. And that power is absolute on a Linux system. There is nothing the root user cannot do, including removing or changing every file on the filesystem. But root access doesn’t simply apply to logging into a system as root – in fact that is a privilege that no one should have. Only a console root login should ever be allowed. In other words, no root access across the network via SSH or any other protocols. Root user access is typically controlled by a super secret password that only a few privileged individuals know. However, there is also root access that can be used via the sudo command. sudo is the standard method that system administrators use to issue commands as root but without the responsibility of being the root user.

The sudo command is generally limited to system administrators. It keeps everyone on a system honest in that sudo must be used before each command that normally would be issued by the root user account. For example, only the root user can stop and start network interfaces:

# ifdown eth0
# ifup eth0

If a user has sudo access, she can issue this command as:

$ sudo ifdown eth0
Password:

The sudo privileged user must enter her own password to prove she is indeed the owner of the account she is using and that she has sudo access. The value of sudo is that commands are entered purposefully using the sudo command and only one command at a time. Once the privileged user has issued a sudo command and prompted for her password, the authentication remains for five minutes only, which is another way of keeping everyone honest by having privileged users reauthenticate periodically.

Alternatively, if a system administrator must become the root user to perform a series of tasks that requires the root user’s environment, she can become root by using su -:

$ su –
Password:

This time the password that’s required is not the user’s password but the actual root user’s password. The advantage of becoming root is that the user then is root and has root’s environment, which is not available to users who use the sudo command. It is imperative that the actual root user’s password be kept secret and only shared with those who really require it. It should also be changed often, which translates to every 30 days for standard production environments.

If administrators have more than a handful of systems to manage, this process can be a bit tedious. The use of LDAP, Active Directory, or NIS+ is recommended in these cases to decrease the number of systems on which the root user’s password must be changed. Having a centralized management interface can also prevent mistyped passwords during a password change event.

Preventing Service Account Logins

Accounts that don’t require shell access should have no standard shell access in the /etc/passwd file. Only actual interactive users and the root user should have a real shell, such as /bin/bash, /bin/ksh, or /bin/csh, for example. All other accounts should either have /bin/false or /bin/nologin for their shell designations, which means that they cannot log in to the system interactively.

Certain accounts will have “pseudo” shells, such as shutdown, sync, and halt, which when used perform those functions. They’re still around for legacy reasons, which were used to allow non-root users the ability to halt or shutdown a system. Unix tradition is that you issue the sync command twice before reboot or halt (shutdown) to write unwritten data to disk. This isn’t necessary anymore, because the system does this itself prior to reboot or halt.

Denying Network Access to the Root Account

It’s easy enough to fix this one, because root logins are disabled by default. Some system administrators enable this feature, including myself, but it’s generally not a good idea. The one possible exception to this is if you have a hardware token and multifactor authentication setup in your environment. But for 99.99 percent of us, leaving this option disabled is exactly what you want to maintain a higher level of security.

The reason for denying network access to the root account might not be immediately obvious. Since most accounts are only protected by a password, root account compromise is only a guess or a brute force attack away. Because of this, you should make becoming root as difficult as possible without impeding productivity.