Sudo Aliases and Exclusions
Pages: 1, 2

You can include aliases in aliases. For example, you could group the DBCOMMANDS alias and the BACKUPS commands into a single group of commands. The included aliases must be defined before they're used.

Cmnd_Alias   DBADMINS = BACKUPS,DBCOMMANDS

sudo can pull group information from the system, and incorporate it into sudoers as a user alias. Rather than explicitly define a user alias, you can give the system group name preceded by a percent sign (%) to indicate it's a group name.

%wheel   ALL = ALL

Anyone in the system's wheel group can issue any command as root, on any server.

Duplicating Alias Names

You can reuse alias names. The user alias DBADMINS is not the same as the DBADMINS command alias. It's quite possible to have sudoer entries like this.

Cmnd_Alias   DBAPP = /usr/home/dbuser/bin/*
Host_Alias   DBAPP = server8,server12,server15
RunasAlias   DBAPP = dbuser,operator
User_Alias   DBAPP = chris,mwlucas
DBAPP        DBAPP = (DBAPP) DBAPP

This is an excellent example of "technically correct, but morally unacceptable." If you do this, anyone who has to debug your sudo configuration will curse your name at great length. On the down side, things like this tend to result in phone calls during the middle of whatever scant hours the senior system administrator is permitted to sleep in.

Now, let's check out a common situation that trips up even experienced systems administrators. Sometimes you want to disallow users from executing certain commands, but give them access to every other command. You can try to do this with the "!" operator, but it's not entirely effective. Since it's a popular setup, however, we'll discuss how this works and then what's wrong with it.

First, define command aliases that contain the forbidden commands. Popular commands to exclude are shells (if you execute a shell as a user, you become that user) and su(1). Then give your user a command rule that excludes those aliases with the ! operator.

Cmnd_Alias   SHELLS = /bin/sh,/bin/csh,/usr/local/bin/tcsh
Cmnd_Alias   SU = /usr/bin/su
mwlucas      ALL = ALL,!SHELLS,!SU

Looks great, doesn't it? And it seems to work.

# sudo sh
Password:
Sorry, user mwlucas is not allowed to execute '/bin/sh' as root on openbsd.
#

Remember, sudo uses full paths for all the commands. You're allowing the user to run any command they want, except for a few that are specified by their full path. All that user needs to do is change their path to one of these commands to run it! The easiest way to do this is by copying the command to another location.

# id
uid=1000(mwlucas) gid=1000(mwlucas) groups=1000(mwlucas), 0(wheel)
# cp /bin/sh .
# sudo ./sh 
# id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 
                  4(tty), 5(operator), 20(staff), 31(guest)
# 

Hello, root!

This sort of restriction can be bypassed trivially, by anyone who understands even the basics of how sudo works. This problem is well-documented in the sudo manual and the other literature. And people still insist upon using it to protect production systems!

If you have users that you do not trust with unrestricted access to the system, do not exclude commands from their sudo permissions. Instead, explicitly list the commands that they may use, and leave it at that. This exclusion can be useful with trusted users (i.e., employees), but only as an advisory. More than once I've logged onto a system and typed "sudo su", only to have sudo remind me that I am not supposed to do that on this system.

This concludes our tour of sudo. You can learn much more about sudo by reading sudo(8), sudoers(5), and the sudo Web page.

Michael W. Lucas

---

Read more Big Scary Daemons columns.

Return to the BSD DevCenter.