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 favourite 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:
/path/program argument(s)
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.
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to fire walls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2001 TechRepublic, Inc.
With the /etc/sudoers file that you provided, people would be better advised to give root password out to everyone, perhaps by means of a yellow Post-it attached to the monitor. Then there wouldn't be a sense of false security.
Both less and vi can switch the files being operated on. Both have shell escapes. That would be a shell with root privileges.
"cat" is a better option for letting people look at logs. "sudo cat file | more" will do the trick without providing unlimited access.
If someone has root powers in vi, they have control of the whole system. At that point, sudo becomes a nice logging system, unless they launcha nother shell to hide the commands that they want to use.
It is also advisable to have a SHELLS alias in the sudoers file so that you can explicitly exclude any shell access to your subcontracted admins. As in "!SHELLS"
The "userdel root" command ought to prove real interesting to see if one can recover without reloading the OS.