10.4. Too Many Tasks, Too Few Qualified Administrators
Sometimes, as a Linux geek, there is too much to do. While you may have several folks who are helping you, they may not have all the skills you expect. They may be fresh out of school, may have qualified with some paper computer certification, or may be in transition from administering operating systems other than Linux.
Newer geeks often learn one service at a time. Once you trust their skills on a service, you set up administrative privileges on a per-command basis.
You don't always have to log in as the root user to administer your systems. In this annoyance, I'll also show you how you can configure access to the sudo command from your regular account. Any command preceded by the word sudo causes the command to run with root privileges, just as if you had issued su first.
Even the best Linux geeks make mistakes. To minimize the effect of mistakes, many geeks disable logins to the root account. Even if root is not disabled, administrators are encouraged to run Linux as a regular user and to use the sudo command when running administrative commands.
Another advantage of sudo is that its use is automatically monitored by Linux. The actual logfile varies by distribution: Red Hat/Fedora uses /var/log/secure, SUSE uses /var/log/messages, and Debian uses /var/log/auth.log. By checking the appropriate file, you can monitor activity by your newer administrators, as well as anyone who might be trying to crack into your system.
A big advantage of sudo is that you don't have to distribute the root password as widely. When another administrator uses sudo to run an administrative command, she is prompted for her regular account password. She does not need to know the root administrative password for that server.
An annoyance associated with sudo is that the shell continues to interpret commands according to the regular user's PATH, not the PATH of the root account. This means that when you issue common system administration commands, such as sudo ifconfig, the shell complains with command not found messages. Either add the directories containing such commands (/sbin and /usr/sbin) to the PATH of each administrator, or get used to issuing commands with full pathnames.
Some of the material in this annoyance is covered in more depth in Linux Security Cookbook by Daniel J. Barrett et al. (O'Reilly).
10.4.1. Full sudo Privileges
By default, regular users aren't allowed to use sudo. You need to specify the accounts of your administrators directly in /etc/sudoers, or add them as a group. The wheel group is often available for this purpose. If security is not a big concern, you can even configure sudo to work from your regular account without passwords.
10.4.1.1. Adding a user to /etc/sudoers
The simplest approach to allow a trusted user to run administrative commands is to specify privileges for that user in the /etc/sudoers file. The best way to edit this file is with the visudo command. It creates a lock file, which prevents multiple administrators from saving different changes to this file, even with other editors.
In our selected distributions, /etc/sudoers includes the following subsection, which provides access to the root account:
#User privilege specification root ALL=(ALL) ALL
If you have a fully trusted user, (such as your regular account), you can add that user with the same privileges. To do so for myself, I add the following line:
michael ALL=(ALL) ALL
With this line, as user michael, I no longer have to log in as root to run administrative commands. For example, I can run the following command to view the basic error log in /var/log/messages:
sudo less /var/log/messages
The first time I run the sudo command from my regular account, I have to enter my account password. I also get a message, the "lecture" described in the sidebar, "The Ubuntu Method":
We trust you have received the usual lecture from the local System Administrator. It usually boils down to two things: #1) Respect the privacy of others #2) Think before you type
If I run the sudo command again within the next five minutes, I don't have to re-enter the password.
If you want to limit user michael's access a bit, you might substitute the following line in your /etc/sudoers:
michael rhel4=(printop) ALL
This directive limits user michael's access to the computer named rhel4, as the user printop, but supports the use of ALL commands, subject to those limits. In other words, directives in /etc/sudoers are in the following format:
localuser host=(target_user) command
10.4.1.2. Securing with the wheel
If you have several users who need administrative privileges, you can configure them as part of the wheel group. wheel is a default group available in Red Hat/Fedora and SUSE Linux, and you can add the group yourself in Debian Linux. I've added a couple of users to my wheel group with the following steps:
Let us analyze the last command line in /etc/sudoers a bit. The example specified that members of the wheel group can run any switch or option associated with the lpc command. You can further limit access in /etc/sudoers to particular options of particular commands. For example, if you wanted to let user nancy reboot her own computer, you could substitute the following line:
nancy ALL = (ALL) shutdown -r now
When you're so specific, the target user is prohibited from running the command with other switches. For example, while user nancy can now run the following command:
sudo /sbin/shutdown -r now
user nancy can't run variations on that command. For example, if she ran the following command to halt the computer:
sudo /sbin/shutdown -h now
she would get an error message to the effect that she's not allowed to run that command as root on the target computer.
You can just as easily substitute a different group for %wheel. Naturally, any group you specify, such as the winos group described earlier in this chapter, has to include the % in front of the group namei.e., %winos.
With the localhost directive, members of the wheel group can run the lpc command only from a local command-line interface. For those members of the wheel group who want to administer printers from a remote workstation, they can log in remotely via ssh.
10.4.1.3. Configuring sudo without passwords
If you run administrative commands frequently, it's annoying to enter your password again and again, even though it's good on some distributions for several minutes after each sudo command you enter. If you're the main administrator, you should already know the root password. Alternatively, you could enter your regular account in the /etc/sudoers configuration file and use your regular password.
However, if entering passwords becomes an annoyance, you can modify the privileges in /etc/sudoers with a line such as the following:
michael ALL=(ALL) NOPASSWD: ALL
In most cases, this is bad for security. With these settings, if someone ever gets access to your regular account, she'll have password-free access to all administrative commands.
If you leave your workstation and are still logged in to your regular account, anyone who sits down at your system has that same password-free access.
10.4.1.4. Aliases in sudoers
You may want to configure multiple users to administer using multiple commands. The directives can get complex. One way to keep things simple is to use aliases when you configure /etc/sudoers. As with aliases in electronic mail, aliases in /etc/sudoers let you cover an arbitrary collection of users by specifying one name.
As noted in the manpage for sudoers, aliases must start with an uppercase letter. If you want to define more than one alias on a line, you can do so by separating the lists with a colon.
Four types of aliases are available:
10.4.2. Managing sudoers
You can provide partial administrative privileges to the users of your choice. The standard Linux method is with appropriate settings in the /etc/sudoers configuration file. Here I show you a couple more things that you can do with this file.
10.4.2.1. Authorizing password changes
One simple task for newer administrators is password management. People forget their passwords all the time. Resetting passwords is an annoyance that you can avoid if you have help.
Sometimes, you'll want to give supervisors or teachers access to the passwd command for their employees or students. As an example, assume that the employees in your group have the following user IDs: drafter1 through drafter9, engineer1 through engineer9, and office1 through office9. First, you can configure the following User_Alias for your supervisors and employees:
User_Alias Supers = cecile,michelle,erin,donna : Employees = drafter[1-9],engineer[1-9], office[1-9]
Now you can add this directive to authorize password privileges for your Supers on all of your systems:
Supers ALL = NOPASSWD: /usr/bin/passwd Employees
Now you can tell your supervisors that they can change employee passwords with the following command:
sudo passwd username
This assumes the username is one of those listed previously.
10.4.3. Disabling Root Logins
When you're working with a number of administrators, discipline is important. You need to discourage administrators from logging in as the root user. Less experienced administrators can accidentally erase whole systems when logged in as root.
Yes, administrators can make mistakes when using sudo. However, anyone who uses sudo should remember that she is administering a system and must take care with any associated commands.
The easiest way to disable direct access to the root account is to modify the login shell in the password configuration file, /etc/passwd. On our selected distributions, the first line in the password configuration file is:
When I change this to:
logins as root are now disabled. If you try logging in directly from the console, you're taken back to the login prompt. If you try logging in to the X Window as the root user, you're given a message to the effect that the account has been disabled. If you try logging in as a regular user and then try accessing the root account via the su command, you're taken back to your regular user prompt.
Then, the only way you can access root administrative commands is via sudo, and only if your account has appropriate privileges in the /etc/sudoers configuration file.