Controlling Root

Carolyn Conner

Most system administrators really believe that only they should know the root password. In reality, though, this can be a difficult concept to practice. Often the politics of the situation determine who has access to root. User justifications such as "It's only a test system, so there is no reason to restrict access to anything" and "This project is high priority, and we need root access to get it done on time" can be very convincing. Regardless of the reasons, root access is often available to people, experienced or not, besides the system administrator, and controlling root access becomes a critical security issue.

There are certain steps that the system administrator can take to make controlling root access possible. First, every effort must be made to provide all users with the appropriate access in a timely manner. Permission issues should be dealt with immediately. After all, if users have the access that they need to get the job done, then they will not request root access. Normally, it starts as a small issue involving individual permissions and escalates quickly into a big problem, especially if the system administrator is perceived as not responding quickly and accurately. Sometimes a quick, correct solution is not possible because permission problems can be complex and difficult to solve. If there are enough complaints from users "not able to do their jobs," the system administrator may be forced to broaden the access to root in order to satisfy user demand. Then the user, as root, can either fix or ignore permission problems to presumably "get the job done." This increases the instability of the situation regardless of the experience of the user who now has root access.

Another argument in favor of giving users root access involves critical user applications that can only be started/stopped by root. Unless some means exists to notify the system administrator that this application is not functioning, the system administrator once again finds himself defending against providing the root password to users. The system administrator needs to respond in a proactive way by correcting the situation before the user becomes involved (i.e., set up automatic paging to notify the system administrator when the application is not functioning). Users will be less inclined to request root access if they know that the system administrator is monitoring their applications and will fix problems immediately.

If some users still need to be weaned from using root, then the second step in controlling root access is to involve the people responsible for data security. This requires that the users, the security group, and Information Services determine jointly which persons need access to root and for what purpose. The list of people who have root access needs to be included in the organization's security policy.

In some cases, only a subset of root access is required. An example would be for the maintenance of user logons. To access the user/group maintenance GUI and perform the function in SUN Solaris, the persons responsible must belong to the sysadmin group. IBM has a system-defined security group with limited root privileges allowing management of users and groups. Hewlett Packard (HP) systems allow SAM (HP System Administration Manager) to be configured with restricted functionality.

Once the persons allowed root access have been determined, then the security group needs the means to monitor their activity. One way to monitor this is to require that root access be obtained only by su'ing to root. All su activity is recorded in the sulog file, which is located, by default, in /var/adm on Sun Solaris 2.3/4/5, IBM AIX 3.2, and HP-UX 10.0. The sulog may be in different locations on other versions of the OS. The format and the information contained in the sulog is as follows and is basically the same format on SUN Solaris, HP-UX, and IBM AIX:

SU   02/19    16:37    -    pts/4     l96453-root
SU   02/19    17:14    +    pts/3     lfq003-l90216
SU   02/20    00:23    +    console   l87002-root

The fields, in order, are the command, which is switch user (su), the date of the su, the time of the su, whether the su attempt was successful (+) or unsuccessful (-), the device/tty where the su occurred, the logon of the user attempting to su, and the su target logon. The first su attempt in the file occurred February 19 at 4:37 p.m. and was an unsuccessful su from device pts/4 by user l96453 to root. The remaining two entries were successful su attempts.

Listing 1 is a script that creates a report from the sulog of su attempts to root based on the date and type of su attempt. The report can help security personnel monitor su attempts to root in order to report deviations from the persons allowed root access. The permissions on the sulog may need to be adjusted so that Security (nonroot users) can execute the script and produce the report. With a few alterations, this script can be run as a cron to automatically produce the report. Because the year is not included on any entry in the sulog, the script was written to assume that the file named sulog is the current year and any past year's information is contained in sulog filenames appended with the appropriate year. Separating the sulog data based on the year is a system administration task that can be done using a cron task. IBM and SUN systems continuously append data to the existing sulog file. HP systems create a new file after each reboot while storing the previous sulog in /var/adm/OLDsulog.

Because the sulog only tracks su attempts, direct logon to root must be prevented or made inconvenient enough so that people will su to root and thereby show up in the sulog. This requires the implementation of step three in controlling root: restricting how root access is achieved and limiting root's system-wide power.

One way to make direct logon to root inconvenient is to restrict it to a specific device such as the console. Su'ing to root suddenly becomes more attractive than direct logon, especially if the console is located in a remote or restricted area. Denying direct logon to root or tying direct root logon to a specific device is not without its hazards. For instance, if the console becomes disabled or logon permissions have been changed so that root is the only one able to logon, then disaster recovery measures may be necessary. Restricting or disabling root through such system changes should not be taken lightly, and the risks should be weighed against the benefits gained from these changes. The following examples are provided to give you an idea of what is available, not as procedures to implement. Thorough research concerning applicability to a particular OS release and the resulting ramifications should be done before implementing any system change.

For SUN Solaris 2.3/4/5, direct logon to root can be restricted to the console or disabled entirely by making changes to the /etc/default/login file. This file is provided with the default of direct root logon from any device. If the parameter CONSOLE is set, direct logon to root can only be done on that device. If CONSOLE is defined as NULL, the only way to access root is to logon as a nonroot user and then su to root. Further information is provided in the /etc/default/login file and SUN documentation of this file. HP-UX 10 provides much the same function as SUN Solaris through the /etc/securetty file. As the default, the file /etc/securetty does not exist on the system. The creation of this file should be done with extreme caution and not without understanding the effects of its existence. The mere creation of this file can deny direct logon to root to all users. Direct logon to root can be restricted to a particular device (i.e., console) or users can be forced to su to root based on the contents of this file. Further information about the file /etc/securetty can be obtained from the man pages for login.

Restricting direct logon to root to a specific device on IBM AIX 3.2 is not as easily accomplished. Several system changes to the root logon must be done as well as the creation of a c program that becomes the primary authentication for the root logon. This documentation can be obtained from IBM Software Support.

The above software changes only affect the direct logon to root. They do not prevent users from su'ing to root if they know the root password. SUN Solaris 2.3/4/5 does not provide a means to allow or disallow specific users the ability to su to root. The only way that I have found to accomplish this is to insert alias statements in the user profiles that prevent them from using the su, alias, unalias, and shell commands. This does require permissions on the profile that prevent users from altering their own profiles. Below are the statements inserted into the user ksh profile:

alias su="echo"This logon cannot su to another user.\"" alias ksh="echo \ "This  \
logon cannot spawn another shell.\""

alias csh="echo"This logon cannot spawn another shell.\"" alias sh="echo \"This  \
logon cannot spawn another shell.\""

alias unalias="echo"This logon cannot use unalias.\"" alias alias="echo \"This  \
logon cannot use alias.\""

HP-UX 10 uses Access Control Lists (ACL) to prevent unauthorized users from su'ing to root by restricting access to the su command. An ACL allows a file owner to permit or deny a list of users, groups, or both access to this file. ACL's are much more flexible than just setting file permissions through UNIX. The specific ACL statements can be obtained from HP Software Support.

IBM AIX 3.2 offers this function through System Management Interface Tool (SMIT). Group and individual su privileges are defined in the user definition screens. The field "SU Groups" specifies which groups can su to this user's account. The field "Another user CAN SU to user?" specifies whether another individual can su to this user account. Even though su access is granted, the individual is still prompted for the password of the account.

Preventing root rexd, ftp, and trusted host access across systems further diminishes root's power and, we hope, the need or desire to use root access. Rexd permits a client to execute a program on a remote machine. Rexd access is controlled by the /etc/inetd.conf file. This entry is commented out as the default. To uncomment this line without change allows every host to be treated as a trusted system and every user to be treated as a trusted user. Adding the -r flag for HP-UX 10 or the -s flag for IBM AIX 3.2 and SUN Solaris 2.3/4/5 makes rexd more secure. These flags allow execution only to those hosts listed in the /etc/hosts.equiv file and to the user on the server associated with the uid sent by the client if there is an entry in that user's $HOME/.rhosts.

Creating a "trusted host" environment, by adding an entry for root either in the /etc/hosts.equiv file or in $HOME/.rhosts on the remote host, bypasses the standard password-based authentication. Root is not prompted for a password when using rlogin to connect to a remote system. Remote commands, such as rcp and rsh, are allowed to execute on the remote host without restriction. The "trusted host" environment is the same for SUN Solaris, HP-UX, and IBM AIX.

File Transfer Protocol (ftp) is used to transfer files between the local host and a remote host or between two remote hosts. ftp does primary authentication, which requires that the user has a valid password. Logon directly to root using ftp is allowed by default. An entry for root in /etc/ftpusers on the local host, prevents use of ftp by root. ftp is the same for SUN Solaris, HP-UX, and IBM AIX.

The preceding discussion deals with limiting root's power and access in an effort to encourage users to use their own logons instead of root. Up to this point, the only monitoring done is recording who has su'ed to root, not what was done once root access was obtained. Depending on the environment, this may be enough. If not, step four in controlling root is the ability to turn on auditing for SUN Solaris, IBM AIX, and HP-UX.

Because auditing provides detailed information on users, objects, and events, it can require a lot of system and administrator resources. Storage is the most highly consumed system resource. Even a simple cat of a file can create about 6 audit records.

The second most consumed resource is the time required to analyze all of the audit data. The more data that is audited, the more records that are produced, and the more time it takes to analyze, report, and archive the data. Analyzing system audit information can easily become another full-time job for the system administrator.

The third most consumed resource by auditing is system processing time. It is less significant than the other two, storage and analysis time, but it could become critical on a busy system. These three resource costs should be considered before starting auditing. A specific security reason for auditing should exist as well, so that it is not just an exercise in system administrator resource consumption.

The first step to controlling root access is quick response to user permission problems and active monitoring of root controlled user processes so that problems with these processes can be handled proactively. This should eliminate the user's desire for root authority.

The second step is to get the people involved to help develop a security policy that specifies who needs root access and why. Enforcement of the security policy can be done by monitoring su access to root. Publishing a weekly report of all "su to root" activity increases awareness of the frequency of this activity and any deviations from the authorized root user list.

The third step is restricting root access and power. Forcing users to su to root allows monitoring of su attempts. It also makes root more inconvenient to use, which may reduce the desire to use the root logon. Root can be further restricted by preventing root rexd, ftp, and "trusted host" access to remote systems. These changes should not, however, be made without a thorough understanding of the consequences.

The fourth step is to determine if there is a security need that justifies implementing system auditing. If so, it is very important to configure the data collection to consist of only the information that is necessary to meet the security goal, thereby conserving system and administrator resources.

The bottom line to controlling root is that the fewer people who have root access, the better. The easiest and least disruptive way to accomplish this is to keep the root password a well kept secret. Even system administrators should avoid using the root account as a means of self-protection, because even the most experienced person can accidentally misuse root privileges and damage the system.

About the Author

Carolyn Conner is a two-year veteran UNIX administrator for Ultramar Diamond Shamrock, a refining and marketing company. She can be reached at: carolyn_conner@diasham.com.