Essential System Administration, 3rd Edition

Becoming Superuser

On a Unix system, the superuser refers to a privileged account with unrestricted access to all files and commands. The username of this account is root. Many administrative tasks and their associated commands require superuser status.

There are two ways to become the superuser. The first is to log in as root directly. The second way is to execute the command su while logged in to another user account. The su command may be used to change one’s current account to that of a different user after entering the proper password. It takes the username corresponding to the desired account as its argument; root is the default when no argument is provided.

After you enter the su command (without arguments), the system prompts you for the root password. If you type the password correctly, you’ll get the normal root account prompt (by default, a number sign: #), indicating that you have successfully become superuser and that the rules normally restricting file access and command execution do not apply. For example:

$ su 
Password:   Not echoed
#

If you type the password incorrectly, you get an error message and return to the normal command prompt.

You may exit from the superuser account with exit or Ctrl-D. You may suspend the shell and place it in the background with the suspend command; you can return to it later using fg.

When you run su, the new shell inherits the environment from your current shell environment rather than creating the environment that root would get after logging in. However, you can simulate an actual root login session with the following command form:

$ su -

Warning

Unlike some other operating systems, the Unix superuser has all privileges all the time: access to all files, commands, etc. Therefore, it is entirely too easy for a superuser to crash the system, destroy important files, and create havoc inadvertently. For this reason, people who know the superuser password (including the system administrator) should not do their routine work as superuser. Only use superuser status when it is needed .

The root account should always have a password, and this password should be changed periodically. Only experienced Unix users with special requirements should know the superuser password, and the number of people who know it should be kept to an absolute minimum.

To set or change the superuser password, become superuser and execute one of the following commands:

# passwd        
            Works most of the time.
# passwd root   
            Solaris and FreeBSD systems when su'd to root.

Generally, you’ll be asked to type the old superuser password and then the new password twice. The root password should also be changed whenever someone who knows it stops using the system for any reason (e.g., transfer, new job, etc.), or if there is any suspicion that an unauthorized user has learned it. Passwords are discussed in detail in Chapter 6.

I try to avoid logging in directly as root. Instead, I su to root only as necessary, exiting from or suspending the superuser shell when possible. Alternatively, in a windowing environment, you can create a separate window in which you su to root, again executing commands there only as necessary.

For security reasons, it’s a bad idea to leave any logged-in session unattended; naturally, that goes double for a root session. Whenever I leave a workstation where I am logged in as root, I log out or lock the screen to prevent anyone from sneaking onto the system. The xlock command will lock an X session; the password of the user who ran xlock must be entered to unlock the session (on some systems, the root password can also unlock sessions locked by other users).^[2] While screen locking programs may have security pitfalls of their own, they do prevent opportunistic breaches of system security that would otherwise be caused by a momentary lapse into laziness.

Tip

If you are logged in as root on a serial console, you should also use a locking utility provided by the operating system. In some cases, if you are using multiple virtual consoles, you will need to lock each one individually.

Controlling Access to the Superuser Account

On many systems, any user who knows the root password may become superuser at any time by running su. This is true for HP-UX, Linux, and Solaris systems in general.^[3] Solaris allows you to configure some aspects of how the command works via settings in the /etc/default/su configuration file.

Traditionally, BSD systems limited access to su to members of group 0 (usually named wheel); under FreeBSD, if the wheel group has a null user list in the group file (/etc/group), any user may su to root; otherwise, only members of the wheel group can use it. The default configuration is a wheel group consisting of just root.

AIX allows the system administrator to specify who can use su on an account-by-account basis (no restrictions are imposed by default). The following commands display the current groups that are allowed to su to root and then limit that same access to the system and admins groups:

# lsuser -a sugroups root 
root sugroups=ALL
# chuser sugroups="system,admins" root

Most Unix versions also allow you to restrict direct root logins to certain terminals. This topic is discussed in Chapter 12.

An Armadillo?

The armadillo typifies one attribute that a successful system administrator needs: a thick skin. Armadillos thrive under difficult environmental conditions through strength and perseverance, which is also what system administrators have to do a lot of the time (see the colophon at the back of the book for more information about the armadillo). System managers will find other qualities valuable as well, including the quickness and cleverness of the mongoose (Unix is the snake), the sense of adventure and playfulness of puppies and kittens, and at times, the chameleon’s ability to blend in with the surroundings, becoming invisible even though you’re right in front of everyone’s eyes.

Finally, however, as more than one reader has noted, the armadillo also provides a cautionary warning to system administrators not to become so single-mindedly or narrowly focused on what they are doing that they miss the big picture. Armadillos who fail to heed this advice end up as roadkill.

Running a Single Command as root

su also has a mode whereby a single command can be run as root . This mode is not a very convenient way to interactively execute superuser commands, and I tend to see it as a pretty unimportant feature of su. Using su -c can be very useful in scripts, however, keeping in mind that the target user need not be root.

Nevertheless, I have found that it does have one important use for a system administrator: it allows you to fix something quickly when you are at a user’s workstation (or otherwise not at your own system) without having to worry about remembering to exit from an su session.^[4] There are users who will absolutely take advantage of such lapses, so I’ve learned to be cautious.

You can run a single command as root by using a command of this form:

$ su root -c "
               command

where command is replaced by the command you want to run. The command should be enclosed in quotation marks if it contains any spaces or special shell characters. When you execute a command of this form, su prompts for the root password. If you enter the correct password, the specified command runs as root, and subsequent commands are run normally from the original shell. If the command produces an error or is terminated (e.g. with CTRL-C), control again returns to the unprivileged user shell.

The following example illustrates this use of su to unmount and eject the CD-ROM mounted in the /cdrom directory:

$ su root -c "eject /cdrom" 
Password:   root password entered 

Commands and output would be slightly different on other systems.

You can start a background command as root by including a final ampersand within the specified command (inside the quotation marks), but you’ll want to consider the security implications of a user bringing it to the foreground before you do this at a user’s workstation.

sudo: Selective Access to Superuser Commands

Standard Unix takes an all-or-nothing approach to granting root access, but often what you actually want is something in between. The freely available sudo facility allows specified users to run specific commands as root without having to know the root password (available at http://www.courtesan.com/sudo/).^[5]

For example, a non-root user could use this sudo command to shut down the system:

$ sudo  /sbin/shutdown ... 
Password:

sudo requires only the user’s own password to run the command, not the root password. Once a user has successfully given a password to sudo, she may use it to run additional commands for a limited period of time without having to enter a password again; this period defaults to five minutes. A user can extend the time period by an equal amount by running sudo -v before it expires. She can also terminate the grace period by running sudo -K.

sudo uses a configuration file, usually /etc/sudoers , to determine which users may use the sudo command and the other commands available to each of them after they’ve started a sudo session. The configuration file must be set up by the system administrator. Here is the beginning of a sample version:

# Host alias specifications: names for host lists
Host_Alias    PHYSICS = hamlet, ophelia, laertes 
Host_Alias    CHEM = duncan, puck, brutus
 
# User alias specifications: named groups of users
User_Alias    BACKUPOPS = chavez, vargas, smith
 
# Command alias specifications: names for command groups 
Cmnd_Alias    MOUNT = /sbin/mount, /sbin/umount 
Cmnd_Alias    SHUTDOWN = /sbin/shutdown
Cmnd_Alias    BACKUP = /usr/bin/tar, /usr/bin/mt
Cmnd_Alias    CDROM = /sbin/mount /cdrom, /bin/eject

These three configuration file sections define sudo aliases—uppercase symbolic names—for groups of computers, users and commands, respectively. This example file defines two sets of hosts (PHYSICS and CHEM), one set of users (BACKUPOPS), and four command aliases. For example, the MOUNT command alias is defined as the mount and umount commands. Following good security practice, all commands include the full pathname for the executable.

The final command alias illustrates the use of arguments within a command list. This alias consists of a command to mount a CD at /cdrom and to eject the media from the drive. Note, however, that it does not grant general use of the mount command.

The final section of the file (see below) specifies which users may use the sudo command, as well as what commands they can run with it and which computers they may run them on. Each line in this section consists of a username or alias, followed by one or more items of the form:

               host = command(s) [: host = command(s) ...]

where host is a hostname or a host alias, and command(s) are one or more commands or command aliases, with multiple commands or hosts separated by commas. Multiple access specifications may be included for a single user, separated by colons. The alias ALL stands for all hosts or commands, depending on its context.

Here is the remainder of our example configuration file:

# User specifications: who can do what where
root          ALL = ALL 
%chem         CHEM = SHUTDOWN, MOUNT
chavez        PHYSICS = MOUNT: achilles = /sbin/swapon
harvey        ALL = NOPASSWD: SHUTDOWN
BACKUPOPS     ALL, !CHEM = BACKUP, /usr/local/bin

The first entry after the comment grants root access to all commands on all hosts. The second entry applies to members of the chem group (indicated by the initial percent sign), who may run system shutdown and mounting commands on any computer in the CHEM list.

The third entry specifies that user chavez may run the mounting commands on the hosts in the PHYSICS list and may also run the swapon command on host achilles. The next entry allows user harvey to run the shutdown command on any system, and sudo will not require him to enter his password (via the NOPASSWD: preceding the command list).

The final entry applies to the users specified for the BACKOPS alias. On any system except those in the CHEM list (the preceding exclamation point indicates exclusion), they may run the command listed in the BACKUP alias as well as any command in the /usr/local/bin directory.

Users can use the sudo -l command form to list the commands available to them via this facility.

Warning

Commands should be selected for use with sudo with some care. In particular, shell scripts should not be used, nor should any utility which provides shell escapes —the ability to execute a shell command from within a running interactive program (editors, games, and even output display utilities like more and less are common examples). Here is the reason: when a user runs a command with sudo, that command runs as root, so if the command lets the user execute other commands via a shell escape, any command he runs from within the utility will also be run as root, and the whole purpose of sudo—to grant selective access to superuser command—will be subverted. Following similar reasoning, because most text editors provide shell escapes, any command that allows the user to invoke an editor should also be avoided. Some administrative utilities (e.g., AIX’s SMIT) also provide shell escapes.

The sudo package provides the visudo command for editing /etc/sudoers. It locks the file, preventing two users from modifying the file simultaneously, and it performs syntax checking when editing is complete (if there are errors, the editor is restarted, but no explicit error messages are given).

There are other ways you might want to customize sudo. For example, I want to use a somewhat longer interval for password-free use. Changes of this sort must be made by rebuilding sudo from source code. This requires rerunning the configure script with options. Here is the command I used, which specifies a log file for all sudo operations, sets the password-free period to ten minutes, and tells visudo to use the text editor specified in the EDITOR environment variable:

# cd 
               sudo-source-directory
# ./configure --with-logpath=/var/log/sudo.log \
                           --with-timeout=10 --with-env-editor

Once the command completes, use the make command to rebuild sudo.^[6]

sudo’s logging facility is important and useful in that it enables you to keep track of privileged commands that are run. For this reason, using sudo can sometimes be preferable to using su even when limiting root-level command access is not an issue.

Warning

The one disadvantage of sudo is that it provides no integrated remote-access password protection. Thus, when you run sudo from an insecure remote session, passwords are transmitted over the network for any eavesdropper to see. Of course, using SSH can overcome this limitation.

---

^[2] For some unknown reason, FreeBSD does not provide xlock. However, the xlockmore (see http://www.tux.org/~bagleyd/xlockmore.html) utility provides the same functionality (it’s actually a follow-on to xlock).

^[3] When the PAM authentication facility is in use, it controls access to su (see Section 6.5).

^[4] Another approach is always to open a new window when you need to do something at a user’s workstation. It’s easy to get into the habit of always closing it down as you leave.

^[5] Administrative roles are another, more sophisticated way of partitioning root access. They are discussed in detail in Section 7.5.

^[6] A couple more configuration notes: sudo can also be integrated into the PAM authentication system (see Section 6.5). Use the - -use-pam option to configure. On the other hand, if your system does not use a shadow password file, you must use the - -disable-shadow option.