sudo

sudo allows privileged roles to be assigned to various users by maintaining a database of privileges mapped to usernames. These privileges are identified by sets of different commands listed in the database. In order to access a privileged item, qualified users simply need to reenter their own passwords (not the root password) after the command name has been entered on the command line. The sudo command permits a user to format disks, for instance, but have no other root privileges.

One of the most useful features of sudo is its logging. By maintaining a log file of all operations performed using the sudo facility, system administrators can audit the log file and trace any actions that may have had unintended consequences. This is something that the normal su facility does not provide. Alternatively, patterns of malicious behavior can also be identified: sudo logs all successful and unsuccessful attempts to perform privileged actions. This can be very important in a security context, because brute force attacks against weak passwords of unprivileged accounts might now be able to access some superuser functions through sudo. Thus, if the user nobody is given access via sudo to format disks, and the password for the user nobody is guessed, an intruder would be able to format disks on the system without requiring the root password. In addition, because the effective user ID of a user executing a privileged application through sudo is set to zero (that is, the superuser), then such applications should not allow shells to be spawned.

All of the roles in sudo are independent. Thus, granting one or more roles to one user and one or more roles to another is possible. User roles can be shared, or they may be completely separate. For example, the user harry may have the privilege to format disks, and the user butler may have the privilege to both format disks and write to tape drives. To access these privileges, harry and butler do not need to know the root password.

The sudo facility is configured by the file /etc/sudoers. This file contains a list of all users who have access to the sudo facility and defines their privileges. A typical entry in /etc/sudoers looks like this:

jdoe    ALL=(ALL) ALL

This entry gives the user jdoe access to all applications as the superuser. For the user jdoe to run commands as the superuser, he or she simply needs to prefix the command string with sudo. Thus, to execute the format command as root, jdoe would enter the following command string:

$ sudo format

The following output will be displayed:

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these two things:

        #1) Respect the privacy of others.
        #2) Think before you type.

Password:

If jdoe correctly types in his or her normal password, the format command will execute with root privileges. If jdoe incorrectly types the password up to three times, the following messages appear after each prompt:

Take a stress pill and think things over.
Password:
You silly, twisted boy you.
Password:
He has fallen in the water!
Password not entered correctly

At this point, an alert is e-mailed to the superuser, informing him or her of the potential security breach—repeated login attempts of this kind may signal a password-guessing attack by a rogue user. Equally, it could indicate that someone is incorrectly typing his or her password (perhaps the CAPS LOCK key is on) or that he or she is entering the root password rather than his or her own.

In order to list all of the privileges currently allowed for a user, that user simply needs to run sudo with the –l option:

$ sudo -l
You may run the following commands on this host:
    (ALL) ALL

In addition to granting full superuser access, sudo can more usefully delegate authority to specific individuals. For example, you can create command aliases that correspond to the limited set of commands that sudo-ers can execute:

Cmnd_Alias  TCPD=/usr/sbin/tcpd

In this case, you are giving users control over the TCP daemon. You can also specify a group of users other than ALL, which share the ability to execute different classes of commands:

User_Alias  DEVELOPERS=pwatters,tgibbs
User_Alias  ADMINS=maya,natashia

Thus, the DEVELOPERS group can be assigned access to specific facilities that are not available to ADMINS. Putting it all together, you can create complex user specifications like this:

ADMINS ALL=(ALL) NOPASSWD: ALL
DEVELOPERS    ALL=TCPD

This specification allows admins to perform operations without a password, while giving developers privileges to operate on the TCP daemon. Notice that we’ve included administrators in the user specification, even though these users probably know the root password. This is because sudo leaves an audit trail for every command executed, meaning that you can trace actions to a specific user account. This makes it easy to find out which individual is responsible for system problems. Of course, these administrators can just use the su facility to bypass the sudo facility, if they know the root password. This is the main drawback of using sudo on Solaris—it is not integrated into the operating system; rather, it is just an application.