sensible sudo-ing

Linux has gone a long way to popularize the use of sudo. While it doesn't seem all that long since common practice involved having multiple admins all logging in as root and doing all of their work without ever logging in with their personal accounts, admins today will generally log in with unprivileged accounts and use more precise sudo commands to do run just the commands that are required by the tasks at hand. This is a big leap forward for security as we can now have some way to tell who has run what privileged commands. That kind of accountability allows you to answer big questions like "What just happened?" when changes on your servers which might otherwise have been very difficult to track down.

Configuration of the sudoers file is, however, still fairly complicated and somewhat tricky. In addition, some of the ramifications of overly generous allocations of privilege may not be readily obvious to anyone new to sudo. Let's take a look at some of these.

One of the key configuration lines in the default /etc/sudoers file on many Linux systems is this line that allows anyone who is a member of the wheel group to run any command on any system with the power of root:

## Allows people in group wheel to run all commands
%wheel  ALL=(ALL)       ALL

The %wheel part of this line means "all members of the wheel group". That syntax, by the way (% followed by the groupname), can be applied to any group that you have defined in your /etc/group file (e.g., %users, %developers, $techsupport -- whatever you've set up).

To find out who is part of the wheel group, you would generally just grep on the /etc/group file, although it is possible that some people might be members by virtue of having this group be their native group (i.e., the one assigned in the /etc/passwd file). This isn't likely the case on Linux servers which tend to put each person in his or her own user group.

Each of the three specifications of "ALL" in the %wheel line shown above each mean something different. The first means all systems, the second all users, and the last all commands. Even this is a bit tricky. I have to review this syntax myself if I haven't looked at /etc/sudoers in a few months. The whole line then means that anyone included in the wheel group -- like sbob and jdoe in the example below -- can run any command with the authority of root.

# grep wheel /etc/group
wheel:x:10:sbob,jdoe

This also means that anyone in the wheel group can run any command as any user (the second ALL). So, the user jdoe could run the command "sudo -u sbob touch /home/sbob/yadda" and create a file in sbob's home that belongs to sbob. Maybe you want your admins to have that kind of control, but this kind of privilege should probably be granted only if it's absolutely needed.

A better strategy would be to restrict sudo commands to running as root. If you change the line shown above to this, your wheel group members will not be able to run commands as other users:

%wheel  ALL=(root)       ALL

Of course, even this syntax does not preclude the use of "sudo su". The su command is, after all, just another command. Anyone who runs the sudo su command would switch to the root account and, from there, work as root without having to prepend each command with "sudo" or have the commands logged. With sudo no longer reviewing the commands that are entered and nothing gettinglogged to /var/log/secure, our wheel users could then operate as root without any further control. The same problem occurs if your admin runs "sudo bash" or "sudo sh" (or sudo followed by the name of any other shells you might have on your system).

To outlaw the use of "sudo su", "sudo bash" and similar commands, you could define a command alias that includes the commands you don't want to be available via sudo:

Cmnd_Alias BANNED = /bin/bash, /bin/sh, /bin/su

and then include the command alias name in your %wheel entry like this:

%wheel  ALL=(ALL)        ALL, !BANNED

Note that this line reads "all commands except those that are in our banned list" (! = NOT). When sbob next tries to "sudo su", he would get the following reaction:

[sbob@penguinista]$ sudo su
[sudo] password for sbob:
Sorry, user sbob is not allowed to execute '/bin/su' as root on penguinista.

If our admin, instead, is restricted to issuing commands with sudo to run them as root, he or she would still likely be prompted to enter his or her password only once every five minutes -- the default for most installations of sudo. This timeout could be changed in the /etc/sudoers file with the timeout option. However, re-authenticating every five minutes does not seem like too much of a burden.

Not having a timeout or having a very short timeout would likely be a hindrance to work getting done. I don't know about you, but I would find the process of entering several dozen commands as root by prefacing each of them with the word sudo and then having to respond to a prompt for my password tiresome as well as distracting, never mind how much it would slow me down. The timeout limit makes sense to me and gives you the ability to capture the sudo user's commands without overburdening him or her with repeated requests to re-authenticate.

NOTE: Banning "sudo su" and similar commands could backfire if your admins cannot su to the root account using root's password. You might want to be sure that your most trusted admin can "sudo visudo" (edit the /etc/sudoers file as root) to ensure that you can easily change the configuration of this file if ever it doesn't work for you.