If you know sudo, you probably know it from Ubuntu, in which you enter your password in return for temporary root privileges. However, Ubuntu's setup is only one of many for sudo. By editing /etc/sudoers, you can configure sudo's password requirements and other features to secure your system in exactly the way you prefer.

Sudo exists for the purposes of minimizing your exposure when you are root user. Because the root account gives full access to your files, your system is at its most vulnerable when you are root. Consequently, you want to minimize your time as root and perhaps even make the root password hard to find.

The sudoers file takes a lot of options, and a careless choice could lock you out of the root account altogether. To avoid this possibility, always edit /etc/sudoers with the visudo command. Visudo creates a temporary copy of sudoers to edit, then checks it for errors. If any errors are found, visudo gives their approximate location by line and gives you three options: to re-open the editor to correct the errors (e); to exit, discarding your edits (X); or to quit (Q) and save the temporary file to the permanent sudoers file. This last option is something that you obviously should not do unless you are very confident that you know better than visudo, because you could prevent sudoers from working at all. Some compilations of visudo, such as Ubuntu's, list the possible choices, whereas others, such as openSUSE's, do not.

Understanding /etc/sudoers

The sudoers file begins with a warning to edit only with visudo. Below it are three main sections.

The usual first section is a list of aliases (Figure 1) with subsections for hosts (host names, IP addresses, network numbers, or netgroups), users (account names, UIDs, groups, or netgroups), run as (account names, UIDs, groups, or netgroups), and commands (sets of related commands, usually with full pathnames). Generally, the aliases are placed first, because they save typing in other sections and can be used to limit user privileges. They are traditionally capitalized to distinguish them from system groups listed in /etc/groups, which are lowercase.

Figure 1: Aliases save typing and help control what root privileges a user can access with sudo.

Regardless of the type of alias, their structure is:

[ALIAS_TYPE] = [ITEM 1], ITEM 2

For example, if you wanted users bb and tk both to use sudo with the same privileges, instead of defining their privileges separately, you could create the alias:

User_Alias ADMIN = bb,tk

Then, when you set up user privileges, you could define privileges for ADMIN, instead of for bb and tk separately. In a similar way, you could define a list of terminals on a network from which a sudo user can log in, or a sub-set of commands, such as apt-get and dpkg, that can be used to limit which root privileges a user logged in to sudo can run.

Typically, the alias section is followed by one labeled in the comments as User privilege specification (Figure 2). This is the section where most of what a user can do is defined. A basic entry uses the structure:

[USER or ALIAS]  [TERMINALS]=[USER RUN AS] [TAGS:] [PERMISSIBLE COMMANDS]

For example, the basic entry for the root user with all privileges is:

root ALL=(ALL) ALL

Figure 2: This section of sudoers defines what commands each sudo user can access.

For other users, you can also specify members of a group listed in /etc/group. For example, in Ubuntu, privileges are defined for members of the groups admin and sudo and only need to be uncommented to become functional. Notice that groups listed in /etc/group are generally in lowercase, whereas aliases defined in sudoers are uppercase, so they can be easily distinguished. A more restricted user privilege specification might be

bb ALL=passwd, chown, chgrp, chmod

which would give user bb the ability to change passwords and permissions from all terminals on the system, while running as root. Alternatively, you might create a command alias called PERMISSIONS that included all four commands:

bb ALL=(ROOT) PERMISSIONS

The third section of sudoers is usually labeled something like Default specification (Figure 3). Sometimes placed at the top of the file, it consists of one specification per line that changes sudoers' default behavior, either in general or for one user or user alias. For example, if you want sudo to insult users when they fail to log in successfully – presumably as a joke or as a way of reinforcing greater caution – the default specifications section might include the line:

Defaults        insults

Figure 3: Default modifications modify how sudo acts.

All entries in sudoers can be turned off by commenting them out. Entries also accept wildcards, such as * for any number of characters or ? for any single character. However, before using wildcards, consider whether they give more permissions than you intended.

Password Options

The most important options for customizing sudoers involves passwords. Before choosing any of them, you need to think carefully about what combination of convenience and security you want.

When a user is listed under specifications or included in a sudoer alias or system group, that user needs only to enter their own password to run as root. This setup is the default option for the user created during installation of Ubuntu. It has the convenience of not requiring that you memorize another password, but it also means that, if your normal account is cracked, then the intruder can easily run root commands. For this reason, you might want to consider other alternatives.

Many of these alternatives will require a separate root password, which Ubuntu deliberately hides. For this reason, before implementing an alternative, you might need to change to a root password of your own choosing by running the command sudo password (Figure 4). This modification will give you more options, while leaving sudo running just as before.

Figure 4: Before some modifications, giving Ubuntu a readable password may be a reasonable precaution.

The sudoers file includes a tag to run root commands without any password. This tag is placed before the list of commands:

bb ALL=(ALL) NOPASSWD:ALL

No doubt NOPASSWD has a role on test machines, but on the average workstation or network, it is even less desirable than Ubuntu's default, because it makes system penetration easy. By contrast, PASSWD: requires a password for all the commands that follow it, which may seem overstrict.

Other password options can be added as default specifications. For example, the line Defaults runpw requires users to give the root password instead of their own. By default, so will Defaults runaspw. However, if runaspw is followed by another user's name, that user's password must be entered instead.

In the same way, Defaults targetpw also defaults to requiring the root password. However, just as with runaspw, targetpw can be used with an account that is used only with sudo. Sudoers can then be set up so that sudo -u USER is required to run specific root commands.

Other specifications can also control access to sudoers. For example, Defaults passwd_tries=[NUMBERS] sets the number of unsuccessful password attempts that can be made before the attempt is logged. An equally important specification is password_timeout=[MINUTES], which sets how long you have root privileges once you log in; a setting of 15 minutes is common in major distributions, but I have heard of timeouts of five minutes, or even two.

Finally, you might consider adding Defaults listpw=always to require a password before the command sudo -l yields its usual summary of sudoer's settings and assigned user privileges. It's a final bit of security that sudoers can give you by manipulating passwords. When you are done, quit the text editor as you normally would.

Other Options and Choices

Sudoers is not just about passwords and logins. Other tags and default specifications define what editor you can use with visudo, as well as the environment you log into, or how and where failed attempts to log in to sudo are stored or mailed. The sudoers man page lists them in full and exhausting detail.

However, few of these other concerns affect how sudo is used as passwords. You do not need to be satisfied with the security that your distribution has chosen – and, in some cases, you should not be. Instead, you can fine-tune sudo exactly as you want.

If you choose, you can build elaborate structures with specialized accounts used only with sudo and assign separate command aliases to them, subdividing access to root commands among the specialized accounts. Or, perhaps you only want a basic structure that seems more secure to you. Either way, sudo provides the building blocks for whatever possibility appeals to you.