sudo, or not sudo: that is the question

If you’ve dabbled even a little bit with security matters, you know that giving root rights or the root password to a common user is a bad idea. But what do you do if a user has a valid need to do something that absolutely requires root rights? The answer is simple: use sudo to grant the user the needed permissions without letting him have the root password, and limit access to a minimum.

With sudo (which stands for “superuser do”), you can delegate a limited set of administrative responsibilities to other users, who are strictly limited to the commands you allow them. sudo creates a thorough audit trail, so everything users do gets logged; if users somehow manage to do something they shouldn’t have, you’ll be able to detect it and apply the needed fixes. You can even configure sudo centrally, so its permissions apply to several hosts.

After you’ve installed and configured your host, users can use sudo aForbiddenCommand to run something they previously couldn’t run. sudo will ask for their password — not the root one — to provide a basic defense against passersby using a console that was left unattended. The users won’t be able to do anything they want; they’ll only be able to do whatever you allow them in the sudo configuration, which minimizes the risk to your system.

Installation and configuration

sudo sports a long history; its first version ran on BSD in around 1980, and since then, updates have come frequently. If it’s not already on your system, you can generally install it from the repositories of your favorite distribution.

sudo is free software, available under an Internet Systems Consortium (ISC)-style license. Both a stable version (currently 1.6.9p12, released on January 20) and a development branch (at version 1.7b1) are available. Because sudo has to do with system security, I encourage you to use the former. If you want to install from source, you can find the source on the GratiSoft Web site. Installation is simple, along the lines of the classical configure, make, make install. However, you might want to check some of the configuration options; for example, you can have sudo insult the user should he enter a wrong password!

Configure sudo by editing /etc/sudoers, which includes, as the name implies, which users can sudo at will. This file has “400” permissions, meaning that only root can read it and nobody can write it. To edit this file, you must use visudo, a program that takes care of the permissions, sets up some locks so two different users can’t edit the file at the same time, and even checks to make sure you didn’t make a mistake before saving it. visudo runs whichever editor you specify in the EDITOR environment variable — usually vi.

The format of the sudoers file is simple: it starts with four optional sections, and it ends with the specific rights assignments. It can include empty lines, or comment lines that start with the # sign. The optional sections are:

• User Alias: Specifies an alias for a single user (not very useful) or a set of users. A user can appear in several aliases.
• “Run as” Alias: Specifies which other user(s) the sudo user will be able to work as. By default, sudo implies root, but you might want to run as another user.
• Host Alias: Specifies the hosts that the rights apply to. You won’t be using this unless you’re doing sysadmin jobs for a group of several Linux boxes. You would have to rsync the file to the other hosts, or use something like Network Information Service (NIS) to provide access to the file.
• Command Alias: Specifies a synonym for a specific command. For instance, it’s easier to type APT than a fully qualified absolute path such as /usr/sbin/apt-get.

You don’t need to use aliases, but they do make future editing easier. For example, if you have to assign donald_duck the same rights that mickey_mouse has, just add the former to the latter’s group, and you won’t have to spend lots of time duplicating lines everywhere. A special alias called ALL exists, and you can use it anywhere; it can mean ALL users, ALL hosts, and so on.

After these sections, you must have a section for specific rights, which looks like “who where = (whoelse) what,” meaning who (a user, a group, or a user alias) on the host where can run a command what as a user whoelse. (If this is too cryptic, look at the following example.) You can also include several specific options, such as NOPASSWD to allow a user to sudo without entering his password; check the manual for the other options.

This sample doesn’t show every configuration possible (for that, you should do man sudoers), but here’s what a sample file with some of these options might look like:

#
# Sample /etc/sudoers file, with apologies to the Disney company!
#

# User aliases
# The first line creates an alias for three specific users.
# The second one includes everybody in the "ducks" user group, but excludes "donald"
# The third one creates an alias for just one user; it can be useful in the future!
#
User_Alias	NEPHEWS = huey, dewey, louie
User_Alias	ALL_DUCKS_BUT_DONALD = %ducks, !donald
User_Alias	MICKEY = mickey_mouse

# Command aliases

Cmnd_Alias      HALT_OR_REBOOT = /sbin/halt
Cmnd_Alias      KILL = /usr/bin/killall
Cmnd_Alias      SHUTDOWN = /sbin/shutdown
Cmnd_Alias      SU = /bin/su

# The rights: who gets to run what

# A standard rule: root, and users in group "wheel", have full rights
root            ALL = (ALL) ALL
%wheel          ALL = (ALL) ALL

# Suppose mickey is an sysadmin; let him run anything without a password
MICKEY		ALL = NOPASSWD: ALL

# NEPHEWS can stop the box if they want
NEPHEWS		HALT_OR_REBOOT, SHUTDOWN

You can also add some extra configuration lines at the end of the configuration file. You can specify, for example:

• Whether emails should be sent for wrong passwords or unallowed attempts to use sudo
• How many login attempts to allow before exiting
• Whether the user should get a short lecture about the risks involved in using sudo
• A log file specific to sudo, where all commands will be logged

When you quit the editor, visudo checks for errors and lets you know whether something is wrong; you can go back to editing or cancel all your changes. The third option, saving the file with an error, can make it impossible for anybody to use the sudo command until you fix the mistake, so that’s not a good idea.

Be careful

When allowing rights, be careful, or you might end up allowing more than you expected. Of course, if you allow a user to do su, then he will get full root rights; did you really want that? This is rather obvious, but there are more subtle traps. For example, if a user is allowed to sudo less, he could then use the ! command and start running any other command as root. (If you don’t know about risks like this, read the Unix man pages that talk about it.) Just in case, before allowing access to a command, check online security sites such as the SANS Institute and search for exploits or vulnerabilities; better safe than sorry.

Another easy mistake is using relative paths for commands; a knowledgeable user could easily hack his way to full rights. Suppose you defined an alias FOO as equivalent to merely bin/foo; a user might be able to create a bin directory somewhere, copy any command he wishes to it (but, most importantly, naming it “foo”), and then run it as root and do anything he wants.

Unfortunately, there’s no guarantee that a user won’t ever be able to find a way to manage a privilege escalation and work as root, but there’s no other easy viable way to allow someone to do something that requires higher levels of access.

While there are some possible risks (mostly having to do with carelessly given rights), using sudo provides you a way to allow specific users to go beyond their normal rights to do specific tasks.