Tracking root Logins

root is inherantly anonymous. If you are the only user with root access, you do not have to worry about this. On systems where multiple users must have the root password, you must ask a question: How much do I trust them? If you are responsible for the integrity of your system you may want to try to at least maintain some accountability. This means at least you would like some record to be made of who became root just before a system event occurred.

Although the measures suggested in this section help, a sophisticated user with root access can disable or circumvent most of them. They are intended to help you track problems or to have some record of who might be responsible when mistakes occur. In addition, because they limit access to root from outside, they will lessen (slightly) exposure of your system to hackers. They will not guard against a malicious user to whom you have given the root password, however.

Improving root accountability is best provided through judicious use of sudo, which can provide root privileges to specific commands, and which can log specific commands executed as root. When direct root logins are allowed, however, the only tracking mechanism is who logged in as root at what time. In order to provide this minimal accounting trail, several configuration changes must be made:

1. authentication messages must be logged remotely. If the log entry of who became root at what time is placed solely on the local machine, the root user can easily modify it, even to make it appear that you were the culprit. The only defense against this is to log events to a remote system with a different root password. We will cover this technique later when we cover the rsyslog program.

2. If the user's identity is unknown when they use su, the log entry is meaningless. Thus, the existence of a guest account on your system can be used to bypass tracking. Any open anonymous accounts should be removed. If they cannot be removed, they should be jailed or at least placed in a restrictive SELinux environment (where they do not have access to su).
   

3. direct root logins must be disabled. This forces users to login to a regular account, then to use su to become root. If the only access they have to the machine is via their personal account, this, when used in conjunction with the previous two techniques, allows you to track who became root at what time.

Disabling direct root logins

If a user is allowed to login directly as root, it is impossible to know who they really are. The only possibility of tracking rests on forcing each user to use the su command to gain root privileges, after logging in as a normal user. In this case a record is made of the change in user in the system log. 

You'd think this would be easy - simply indicate somewhere that direct root logins are not allowed, and that's it. This may indeed be possible using PAM, but the author is not yet an expert in this technique. Instead we will attack the problem by configuring each of the pathways that can lead to authentication to disable directly logging in as root.

Traditionally, all authentications on the system were done via one mechanism, login. Today, unfortunately, several programs can begin authentication depending on where you login from:

• logging in remotely via telnet or ftp. If you allow this method of login, you don't care much about security already, as your passwords are being broadcast over the Internet. Disabling direct root logins is the least of your worries.

• logging in remotely via ssh. Disallowing direct root logins is configurable in sshd by adding the configuration option

• logging into the console using Xwindows. We are assuming your login to the X console is proceeding through gdm, the GNOME display manager. How direct root logins are disabled via gdm depends on its version. gdm versions used prior to RHEL 6 were not PAM-aware, and root logins can be disabled by adding the following options (again, make sure they are uncommented)

to the graphical display manager gdm. The configuration file is in the [security] section of

If your version of gdm is PAM-aware (as they are on both 6.5 and 7), you must disable direct root login using PAM.

• logging into one of the virtual terminals. These include the console of a machine not running Xwindows or any of the parallel 'virtual consoles' that have a login running accessible using Cntl-Alt-FunctionN. Whether root login is permitted on a device used for a dumb terminal is controlled by the file /etc/securetty. The rules are as follows:

1. If the file does not exist, all virtual consoles are considered 'secure', and root logins are permitted on any virtual console. (A console that is running a dumb terminal.)
   

2. If the file exists, only the  devices of virtual consoles that appear in it are considered 'secure'. For example, if /dev/tty1 is considered 'secure', a line in /etc/securetty that simply has tty1 starting in column #1 will permit root logins on that console whenever it has a dumb terminal running on it. Normally, the securetty file has all the possible [uncommented] device names for virtual consoles listed in it, thus allowing direct root logins on any of them. To disable direct root logins, simply comment out all of the lines.
   

   You can tell which consoles are active by examining the the ACTIVE_CONSOLES parameter in the file /etc/sysconfig/init. For example, if the line is

Whether the securetty file is honored is determined by your PAM configuration. Look for securetty in the /etc/pam.d/login file.