Administrative Controls

When administering a home machine, the user will have to perform some tasks as the root user or by acquiring effective root privileges via a setuid program, such as sudo or su. A setuid program is one that operates with the user ID (UID) of the owner of program rather than the user operating the program. Such programs are denoted by a lower case s in the owner section of a long format listing.

For a system administrator, however, choices must be made as to how much administrative access each users within the organization should have to their machine. Through a PAM module called pam_console.so, some activities normally reserved only for the root user, such as rebooting and mounting removable media are allowed for the first user to log in at the physical console (see the chapter titled Pluggable Authentication Modules (PAM) in the Official Red Hat Linux Reference Guide for more on the pam_console.so module). However, other important system administration tasks such as altering network settings, configuring a new mouse, or mounting network devices are impossible without administrative access. As a result system administrators must decide how much to trust the users on their network.

Allowing Root Access

If the users within an organization are a trusted, computer-savvy group, then allowing them root access may not be a bad thing. Allowing root access users means that minor issues like adding devices or configuring network interfaces can be handled by the individual user, leaving system administrators free to deal with network security and other important issues.

On the other hand, giving root access to individual users can lead to the following issues (to name a few):

Disallowing Root Access

If an administrator is uncomfortable allowing users to log in as root for these or other reasons, the root password should be kept secret and access to runlevel one or single user mode should be disallowed through boot loader password protection (see the Section called Boot Loader Passwords for more on this topic).

Table 4-1 shows ways an administrator can further ensure that root logins are disallowed:

Table 4-1. Methods of Disabling the Root Account

MethodDescriptionEffectsDoes Not Effect
Disabling root SSH logins.Edit the /etc/ssh/sshd_config file and set the PermitRootLogin parameter to no.

Prevents root access via the OpenSSH suit of tools. The following programs are prevented from accessing the root account:
ssh
scp
sftp

Since this only effects the OpenSSH suite of tools, no other programs are effected by this setting.

Changing the root shell.Edit the /etc/passwd file and change the shell from /bin/bash to /sbin/nologin.

Prevents access to the root shell and logs the attempt.
The following programs are prevented from accessing the root account:
login
gdm
kdm
xdm
su
ssh
scp
sftp

Programs that do not require a shell, such as FTP clients, mail clients, and many setuid programs.
The following programs are not prevented from accessing the root account:
sudo
� FTP clients
� Email clients

Disabling root access via any console device (tty).An empty /etc/securetty file prevents root login on any devices attached to the computer.

Prevents access to the root account via the console or the network. The following programs are prevented from accessing the root account:
login
gdm
kdm
xdm
� Other network services that open a tty

Programs that do not log in as root, but perform administrative tasks through through setuid or other mechanisms.
The following programs are not prevented from accessing the root account:
su
sudo
ssh
scp
sftp

Use PAM to limit root access to services.Edit the file for the target service in the /etc/pam.d/ directory. Make sure the pam_listfile.so is required for authentication. See the Section called Disabling Root Using PAM for more details.

Prevents root access to network services that are PAM aware.
The following services are prevented from accessing the root account:
� FTP clients
� Email clients
login
gdm
kdm
xdm
ssh
scp
sftp
� Any PAM aware services

Programs and services that are not PAM aware.

Disabling the Root Shell

If the administrator does not wish for users to log in directly as root, he can set the root account's shell to /sbin/nologin in the /etc/passwd file. This will prevent access to the root account through commands that require a shell, such as the su and the ssh commands.

ImportantImportant
 

Programs that do not require access to the shell, such as email clients or the sudo command, can still access the root account.

Disabling Root Logins

To further enforce this, he can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether it by via the console or a raw network interface. This is dangerous because if configured in this way, a user could telnet into his machine as root, sending his password in plain text over the network. By default, Red Hat Linux's /etc/securetty file only allows the root user to log at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command:

echo > /etc/securetty

WarningWarning
 

A blank /etc/securetty file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication.

Disabling Root SSH Logins

To prevent root logins via the SSH protocol, you will need to edit the SSH daemon's configuration file: /etc/ssh/sshd_config. Change the line that says:

# PermitRootLogin yes

To read as follows:

 
PermitRootLogin no

Disabling Root Using PAM

PAM allows great flexibility in denying specific accounts via the /lib/security/pam_listfile.so module. This allows the administrator to point the module at a list of users that are not allowed to log in. Below is an example of how the module is used for the FTP service in the /etc/pam.d/ftp PAM configuration file (the \ character at the end of the first of the first line is not necessary if the directive is all on one line):

auth   required   /lib/security/pam_listfile.so   item=user \
sense=deny file=/etc/ftpusers onerr=succeed

This tells PAM to consult the file /etc/ftpusers and deny any user listed access to the service. The administrator is free to change the name of this file and can keep separate lists for each service or use one central list to deny access to multiple services.

If the administrator wants to deny access to multiple services, he can add a similar line to the PAM configuration services, such as /etc/pam.d/pop and /etc/pam.d/imap for mail clients or /etc/pam.d/ssh for SSH clients.

For more information about PAM, see the chapter titled Pluggable Authentication Modules (PAM) in the Official Red Hat Linux Reference Guide.

Limiting Root Access

Often, rather than completely deny access to the root user, the administrator may wish to allow access only via setuid programs, such as su or sudo.

The su Command

When a user types the command su she is prompted for the root password and, after authentication, given a root shell prompt.

Once logged in via the su command, the user is the root user and has absolute administrative access to the system. In addition, once a user has attained root, it is possible in some cases for them to use the su command to change to any other user on the system without being prompted for a password.

Because this program is so powerful, administrators may wish to limit who has access to the command.

One of the simplest ways to do this is to add users to the special administrative group called wheel. To do this, type the following command as root:

usermod -G wheel username

To use the User Manager for this purpose, go to the Main Menu Button (on the Panel) => System Settings => Users & Groups or type the command redhat-config-users at a shell prompt. Select the Users tab, select the user from the user list, and click Properties from the button menu (or choose File => Properties from the pull-down menu).

Then select the Groups tab and click on the wheel group, as shown in Figure 4-2.

Figure 4-2. User Groups Pane

Next open the PAM configuration file for su, /etc/pam.d/su, in a text editor and remove the comment [#] from the following line:

auth  required /lib/security/pam_wheel.so use_uid

Doing this will permit only members of the administrative group wheel to use the program.

NoteNote
 

The root user is part of the wheel group by default.

The sudo Command

The sudo command offers another approach for giving trusted users administrative access. When a trusted user precedes an administrative command with sudo, he is prompted for his password. Then, once authenticated and assuming that the command is permitted, the administrative command is executed as if by the root user.

The basic format of the sudo command is as follows:

sudo command

In the above example, command would be replaces by a command normally reserved for the root user, such as mount.

ImportantImportant
 

Users of the sudo command should take extra care to log out when they walk away from their machine since sudoers can use the command again without being asked for a password until a five minute period has passed. This setting can be altered via the configuration file, /etc/sudoers.

The sudo command allows for a high degree of flexibility. For instance, only users listed in the /etc/sudoers configuration file are allowed to use the sudo command and the command is executed in their shell, not root's. This means the root shell can be completely disabled, as shown in the Section called Disabling the Root Shell.

The sudo command also provides a comprehensive audit trail. Each successful authentication is logged to the file /var/log/messages and command that was issued along with the issuer's user name is logged to the file /var/log/secure.

Another advantage of the sudo command is that an administrator can allow different users access to specific commands based on their needs.

All commands executed via sudo are recorded in the /var/log/secure file, as well as all attempts to use the sudo command.

Administrators wanting to edit the sudo configuration file, /etc/sudoers, should use the visudo.

To give someone full administrative privileges, type visudo and add a line similar to the following in the user privilege specification section:

juan ALL=(ALL) ALL

This example states that the user, juan, can use sudo from any host and execute any command.

The example below illustrates the granularity possible when configuring sudo:

%users  localhost=/sbin/shutdown -h now

This example states that any user can issue the command /sbin/shutdown -h now as long as they issue it from the console.

The man page for sudoers has a detailed listing of options for this file.