Section 10.4. Too Many Tasks, Too Few Qualified Administrators | Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It

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.

In "Securing by User," at the end of this chapter, I'll show you how you can use Pluggable Authentication Modules (PAM) to support access to individual administrative tools.

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).

The Ubuntu Method

Ubuntu is one distribution quickly gaining popularity as a version of Linux that's great for the desktop. Part of its appeal is the way it controls access to the administrative account. The root account is disabled in /etc/shadow, with the use of an asterisk in the second (password) column. Nobody can log in as root, or su to the root account (except with the sudo su command).

The proper way to run administrative commands in Ubuntu is with the sudo command. The defaults are unique in Ubuntu's /etc/sudoers and are something you should consider on other distributions:

 Defaults   !lecture,tty_tickets,!fqdn

As you should know, the "bang," represented by the exclamation point (!), reverses the intent of a function. The first directive (!lecture) disables the lecture function that warns regular users about administrative commands. tty_tickets requires separate password entries when sudo is run on different terminals. Finally, !fqdn disables any requirement for Fully Qualified Domain Names.

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.

It's possible to edit /etc/sudoers from the regular administrative account with the editor of your choice. But there is no lock, and others can edit this file simultaneously. Only visudo creates a lock that prevents others from editing this file with any regular text editor in Linux. visudo doesn't require you to use the vi editor; as with many interactive commands, it checks your EDITOR environment variable, which you can set to emacs, nedit, or any other editor you prefer.

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 I'm a bit more paranoid about security, I might want users to enter their password every time they use sudo to run an administrative command. To do so, I include the Defaults timestamp_timeout = 0 directive in /etc/sudoers.

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:

I opened the /etc/group file and navigated to the preconfigured wheel group, which is associated with GID 10 in Red Hat/Fedora and SUSE Linux; it looks similar to:
```
 wheel:x:10: 
```
If you're in Debian Linux, you'll need to create the wheel group yourself. As Debian's GID 10 is already assigned to the uucp user, you'll have to associate wheel with a different GID. (Remember, GIDs below 100 are reserved for services, and those above 100 are associated with regular users and groups.) Some judgment is required. You might want to select a high GID. In my case, GID 11 was available, and I added the following line:
```
 wheel:x:11: 
```
I added the desired users to the wheel group. By definition, users in a group are defined in the fourth column of that group. The result will look similar to:
```
 wheel:x:11:nancy,randy 
```
You can also use GUI tools that assign users to groups, such as Fedora's system-config-users.
I saved the result. For distributions associated with the shadow password suite (where passwords are encrypted in the root-only /etc/shadow file), you'll want to make sure your changes are reflected in the group shadow file, /etc/gshadow. You can do so with the following command:
```
 grpconv 
```
I opened the /etc/sudoers file with the visudo command. If, as a regular user, you already have privileges in /etc/sudoers, you can do so with the following command (otherwise, you'll have to log in as root):
```
 sudo /usr/sbin/visudo 
```
I then configured the wheel group with appropriate privileges. In this case, I allowed the users in the wheel group to configure printers with the lpc command, by adding the following line to /etc/sudoers.
```
 %wheel localhost=/usr/sbin/lpc 
```
Once saved, I told my administrators that they can start using lpc to administer printers on this system, using sudo.

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:

User_Alias

If you don't want to bother with another group, you can use the User_Alias directive to define a group of users, such as:

 User_Alias    Managers = cindy,linda,wendy : Teachers = mike,rick,cliff

Runas_Alias

The Runas_Alias directive defines users with desired permissions. For example, if you've configured a Printer Administrator (printadm) and a Database Manager (dbmgr) with special permissions, you could configure a Runas_Alias to represent multiple users with a directive such as:

 Runas_Alias    PA = root,printadm Runas_Alias    DA = root,dbmgr

Host_Alias

When you configure a Host_Alias, you configure multiple computers with a single alias. For example, the following directive configures MAILERS as the Host_Alias for the hosts named mail1, mail2, and mail3.

 Host_Alias   MAILERS = mail1,mail2,mail3 You could also configure a Host_Alias as a subnet, substituting 192.168. 0.0/24 for mail1,mail2,mail3.

Cmnd_Alias

If you want to configure multiple commands for a specific user, you can use the Cmnd_Alias to represent them. For example, the following directive configures PRTCMDS as representative of the lpc and lprm commands.

 Cmnd_Alias   PRTCMDS = /usr/sbin/lpc,/usr/sbin/lprm

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:

 root:x:0:0:root:/root:/bin/bash

When I change this to:

 root:*:0:0:root:/root:/bin/false

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.

The one time where it may be best to log in as the root user is during the Red Hat certification exams. The tasks associated with these exams are all administrative and generally require root user permissions. When logged in as root, your PATH supports easier access to administrative commands. (For example, as root, you can run the ifconfig command without typing in the full path to the command.) The time you save by not having to enter a password or a full directory path can give you the extra few minutes that you need to pass the Red Hat exams.