Although some of us administrators may hesitate to admit it, it is often necessary to relinquish some control and delegate responsibility, especially in multiadministrator environments. Fortunately, you can easily delegate administrative duties on your Linux systems without giving out the root password. Just use Sudo.
The concept behind Sudo (derived from "superuser do") is quite genius in its simplicity: Allow specified users or groups to run root-level commands based on a central configuration file. Sudo also provides verbose logging of all commands and arguments so you can track its usage, which is extremely helpful in tracking problems created by misconfigurations and input error.
If you have ever administered a server on which multiple users need root access, you will immediately see the benefits of Sudo. Here's a look at how you can take advantage of it.
Installing and configuring Sudo
You can obtain Sudo from a variety of locations, but you'll find the latest version here, as well as links to current source packages and different binaries. Some Linux distributions come with Sudo preinstalled or at least have it available as part of their installation CDs.
After you have installed Sudo on your system(s), you will need to modify the configuration file to meet your needs. This file, usually /etc/sudoers, is a plain text file that allows an administrator to outline which users may access which programs and files. You'll also be able to create groups to which certain users and commands can be assigned, making administration that much easier.
The documentation for Sudo advises the use of visudo, an editing program provided with the package, to modify the /etc/sudoers file. Fortunately, visudo not only locks /etc/sudoers to prevent simultaneous modifications but will also check your syntax for any errors. Of course, you may just prefer to use your favorite text editor to set up the sudoers file manually.
Before beginning to configure Sudo, it is a good idea to map out what servers, programs, and commands specific users will need to have access to. For example, what commands relating to the administration of Sendmail, BIND, or Apache can be delegated to other groups? Perhaps you do not want them restarting the daemon, but maybe they can be allowed to add new users or domains. Listing 1 shows an example sudoers file.
Parameters in the sudoers file
In the listing, you can see how groups of systems, users, and commands are created with the Host_Alias, User_Alias, and Cmnd_Alias parameters. Let’s start with the Host_Alias entry. As long as the /etc/sudoers file can be accessed from each server, multiple hosts can share the same file. In our example, we have created three aliases for our servers and entered one per line. The server names ns1, ns2, mail1, mail2, mail3, and web1 are the local host names for each machine. When a user executes sudo from the command line on one of these servers, Sudo will check the local hostname and provide access based on what it finds. This allows for host-based access, which is helpful since commands often vary depending on the server’s role.
The User_Alias command allows us to classify system users and/or groups into a single variable. This variable is then used to grant privileges. There are two aliases in this example, NOC and CALLCENTER. NOC consists of two system accounts: steve and mike, and one system group: noc. Notice the % sign, which tells Sudo to interpret the word that follows as a local group. You will need to create these groups and add users before using them in the sudoers file.
You use the Cmnd_Alias parameter to commands. As you can see, there are five groups of commands: READLOG, USERMOD, RESTART, MODIFY, and ROOTMOD. Since different groups will require different kinds of access, you can break commands into easy-to-manage blocks. You enter commands as follows:
Sudo will continue to the next line if ", \" is encountered. Command aliases can be valuable in this regard, since not every group will need every command available to Sudo.
Some commands should be explicitly denied for particular users and/or groups, as you can see in the next-to-last example in our sudoers file. Be as specific as possible in this section and the command section that it relates to. Notice that there are two entries for the same command under ROOTMOD, taking into account the different switches a command can use. Also, in the MODIFY group, access is given to both the pico and vi text editors, based on a user’s preference.
It's important to know what capabilities each program has. The file viewer less, for instance, has a default option that allows you to access a shell. Without recompiling less, a user with Sudo access to it could easily gain a root shell. It is often the small things that cause large problems later, so go over your final draft a few times before implementing it on your production systems.
Now let's look at the syntax for assigning permissions to users. After you set up the aliases, you can apply them using the following format:
Commas separate multiple host aliases and command aliases. Command aliases are denied with a preceding "!" as in the example of ROOTMOD in our sample sudoers file. This is a failsafe in the event that a user/administrator attempts to do something he or she shouldn’t be doing. In this case, a NOC member has access to add and delete local users but should not be able to make any changes to the root account. As this example illustrates, Sudo will not automatically distinguish between good and bad behavior; this is left up to the administrator assigning the permissions.
After configuring Sudo, it is refreshingly simple to use. There is not much of a learning curve for those who need to use it. The hardest part is to remember to put sudo before issuing a command usually restricted to root. Upon its first usage, Sudo requires the user to enter his or her password. Sudo can then be used without entering a password. However, after five minutes of not using the program, a timeout will occur, and a password will be required for the next run. (This timeout period can be modified at compile time.)
The basic execution of Sudo is done as sudo <command>, as in the following example:
mail1$ sudo less /var/log/mail.log
As mentioned above, Sudo will log this and all execution attempts. The specific file logged to will vary from system to system but is commonly /var/log/messages or /var/log/auth.log. This can also be modified at compile time. The Sudo log entry will look similar to Listing 2.
The logs will help in tracking down possible holes in your configuration as well as providing accountability. This is much better than a shared root password where it can be difficult to tell which user performed what command. Sudo tells you exactly who did what, and when they did it.
Decentralization of Linux security has never been easier than when Sudo is used to its full extent. Administrative tasks can easily be delegated to different users and groups without the worry of giving out full root access. Commands can be placed into groups and access granted to users or groups of users based on individual hosts. Overall security is maintained while productivity is increased. Sudo is nothing less than essential in a multiadministrator environment.
Have a comment or a question?
We look forward to getting your input and hearing about your experiences regarding this topic. Post a comment or a question about this article.