When administering a home machine, the user must 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 program's owner rather than the user operating the program. Such programs are denoted by an s in the owner section of a long format listing, as in the following example:
-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su
The s may be upper case or lower case. If it appears as upper case, it means that the underlying permission bit has not been set.
For the system administrators of an organization, however, choices must be made as to how much administrative access 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 that logs in at the physical console (refer to "Pluggable Authentication Modules (PAM)" for more information about 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 not possible without administrative privileges. As a result, system administrators must decide how much access the users on their network should receive.
Allowing Root Access
If the users within an organization are trusted and computer-literate, then allowing them root access may not be an issue. Allowing root access by users means that minor activities, like adding devices or configuring network interfaces, can be handled by the individual users, 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:
- Machine Misconfiguration - Users with root access can misconfigure their machines and require assistance to resolve issues. Even worse, they might open up security holes without knowing it.
- Running Insecure Services - Users with root access might run insecure servers on their machine, such as FTP or Telnet, potentially putting usernames and passwords at risk. These services transmit this information over the network in plain text.
- Running Email Attachments As Root - Although rare, email viruses that affect Linux do exist. The only time they are a threat, however, is when they are run by the root user.
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 (refer to "Boot Loader Passwords" for more information on this topic.)
The following are four different ways that an administrator can further ensure that root logins are disallowed:
- Changing the root shell
-
To prevent users from logging in directly as root, the system administrator can set the root account's shell to /sbin/nologin in the /etc/passwd file.
Table 46.1. Disabling the Root Shell
gdm
kdm
xdm
su
ssh
scp
sftp
FTP clients
Email clients
| Effects
| Does Not Affect
|
|
Prevents access to the root shell and logs any such attempts. The following programs are prevented from accessing the root account:
|
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: |
- Disabling root access via any console device (tty)
-
To further limit access to the root account, administrators 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 via the console or a raw network interface. This is dangerous, because a user can log in to their machine as root via Telnet, which transmits the password in plain text over the network.
By default, Community Enterprise Linux's /etc/securetty file only allows the root user to log in at the console physically attached to the machine. To prevent the root user from logging in, remove the contents of this file by typing the following command at a shell prompt as root:
echo > /etc/securetty
To enable securetty support in the KDM, GDM, and XDM login managers, add the following line:
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
to the files listed below:
/etc/pam.d/gdm-autologin
/etc/pam.d/gdm-fingerprint
/etc/pam.d/gdm-password
/etc/pam.d/gdm-smartcard
/etc/pam.d/kdm
/etc/pam.d/kdm-np
/etc/pam.d/xdm
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.
Table 46.2. Disabling Root Logins
gdm
kdm
xdm
Other network services that open a tty
sudo
ssh
scp
sftp
| Effects
| Does Not Affect
|
|
Prevents access to the root account via the console or the network. The following programs are prevented from accessing the root account:
|
Programs that do not log in as root, but perform administrative tasks through setuid or other mechanisms. The following programs are not prevented from accessing the root account: |
- Disabling root SSH logins
-
To prevent root logins via the SSH protocol, edit the SSH daemon's configuration file, /etc/ssh/sshd_config, and change the line that reads:
#PermitRootLogin yes
to read as follows:
PermitRootLogin no
Table 46.3. Disabling Root SSH Logins
scp
sftp
| Effects
| Does Not Affect
|
|
Prevents root access via the OpenSSH suite of tools. The following programs are prevented from accessing the root account:
|
Programs that are not part of the OpenSSH suite of tools. |
- Using PAM to limit root access to services
-
PAM, through the /lib/security/pam_listfile.so module, allows great flexibility in denying specific accounts. The administrator can use this module to reference a list of users who are not allowed to log in. To limit root access to a system service, edit the file for the target service in the /etc/pam.d/ directory and make sure the pam_listfile.so module is required for authentication.
The following is an example of how the module is used for the vsftpd FTP server in the /etc/pam.d/vsftpd PAM configuration file (the \ character at the end of the first line is not necessary if the directive is on a single line):
auth required /lib/security/pam_listfile.so item=user \
sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
This instructs PAM to consult the /etc/vsftpd.ftpusers file and deny access to the service for any listed user. The administrator can 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, a similar line can be added to the PAM configuration files, 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, refer to "Pluggable Authentication Modules (PAM)".
Table 46.4. Disabling Root Using PAM
gdm
kdm
xdm
ssh
scp
sftp
FTP clients
Email clients
Any PAM aware services
| Effects
| Does Not Affect
|
|
Prevents root access to network services that are PAM aware. The following services are prevented from accessing the root account:
|
Programs and services that are not PAM aware. |
Limiting Root Access
Rather than completely denying access to the root user, the administrator may want to allow access only via setuid programs, such as su or sudo.
The su Command
When a user executes the su command, they are prompted for the root password and, after authentication, is 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 become root, it is possible 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 within an organization 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>
In the previous command, replace <username> with the username you want to add to the wheel group.
You can also use the User Manager to modify group memberships, as follows. Note: you need Administrator privileges to perform this procedure.
-
Click the System menu on the Panel, point to and then click Users and Groups to display the User Manager. Alternatively, type the command system-config-users at a shell prompt.
-
Click the Users tab, and select the required user in the list of users.
-
Click Properties on the toolbar to display the User Properties dialog box (or choose Properties on the File menu).
-
Click the Groups tab, select the check box for the wheel group, and then click OK. Refer to Figure 46.2, "Adding users to the "wheel" group.".
-
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/$ISA/pam_wheel.so use_uid
This change means that only members of the administrative group wheel can use this program.
Figure 46.2. Adding users to the "wheel" group.
The root user is part of the wheel group by default.
The sudo Command
The sudo command offers another approach to giving users administrative access. When trusted users precede an administrative command with sudo, they are prompted for their own password. Then, when they have been authenticated and assuming that the command is permitted, the administrative command is executed as if they were the root user.
The basic format of the sudo command is as follows:
sudo <command>
In the above example, <command> would be replaced by a command normally reserved for the root user, such as mount.
Users of the sudo command should take extra care to log out before walking away from their machines since sudoers can use the command again without being asked for a password within a five minute period. 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 the user's shell, not a root shell. This means the root shell can be completely disabled, as shown in "Disallowing Root Access".
The sudo command also provides a comprehensive audit trail. Each successful authentication is logged to the file /var/log/messages and the command 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.
Administrators wanting to edit the sudo configuration file, /etc/sudoers, should use the visudo command.
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 it is issued from the console.
The man page for sudoers has a detailed listing of options for this file.
