Aliases are good ways to group commands together or create a shorthand version for something. There are four different kinds of aliases: Runas aliases, User aliases, Command aliases, and Host aliases. Aliases are very easy to define. Simply indicate what kind of alias you’re defining, provide a name for the alias, and then provide the value for the alias. Values can be comma-delimited when multiple values are being assigned to that alias name. The type of alias is provided using one of the following keywords. I’ve also included a description of what exactly each alias is for.
Cmnd_Alias: A list of commands to group together. These commands are comma-delimited. It is recommended that you use the full path of the command, which means using /bin/cp instead of cp, for instance. Commands can also be a list of files that you prefix with the command sudoedit. This allows users who have this alias assigned to them to be able to edit the files. For example, see the LDAP alias below for how to use sudoedit. For commands, you can use wildcards too just as you would on the command line.
Host_Alias: A list of one or more hosts. You can specify the host(s) that a user is allowed to run a command on, and you can group them together using a host alias. You can use IP addresses, network addresses, netgroups (with a ‘+’), or DNS hostnames. If you specify a network address, you can include the netmask in either full form (255.255.255.0) or CIDR shorthand form (/24). Without a netmask, sudo will attempt to determine the netmask automatically by checking each active network card on the system for a matching network address.
User_Alias: A list of one or more users. Users are listed either by using individual names, UIDs, local groups, network groups, or by excluding users to do an “all except” list. Individual users are designated by simply putting the username. Using a ‘#’ at the beginning of a value will indicate the value is a UID instead of a username. Local groups are prefixed using a ‘%’ and network groups are prefixed with a ‘+’. To exclude users, use a ‘!’ before the username. Multiple ‘!’ will either have the “not” effect if there’s an odd number or negate the exclusion if there is an even number.
Runas_Alias: This is very similar to a User alias. It is also a list of users, but instead of being a list of users to assign permissions to, it’s a list of users that you can run commands as. So these would be used when using the -u option of the sudo command. All prefixes for various types of values are the same as the User alias prefixes.
So, for instance, you can define a command alias to group all LDAP commands together:
Cmnd_Alias LDAP = /usr/bin/ldapadd, /usr/bin/ldapdelete, /usr/bin/ldapmodify, sudoedit /etc/openldap/*
This means that later on when you define a user with sudo access, you can use this alias in place of listing each command. The format for each alias group is the same as the command alias. Aliases should go before any user or group sudo permission definitions.
One last alias to note is the ALL alias. It’s not one that ever shows up in the sudoers file because it’s built-in and inherently understood by the sudo command. ALL, as you can imagine, stands for all commands, hosts, users, or RunAs users, depending on where you use it. You’ll see more examples of it later on in the tutorial, but as a quick explanation, imagine you want to be able to run a command as any user on the system. Instead of listing each user or creating a RunAs alias, you can just put ALL in place of the RunAs user field. This way, you never need to update the alias as you add users.
Now we’re on to the user specifications. This is the area where you actually define who gets to run what commands as which users. The basic format is as follows:
User Host = (RunAs User) Cmd1, Cmd2, ..., Cmdn
So to allow user Bob to run /bin/ls as user Tim on all hosts (remember that ALL alias I mentioned?), you would specify:
Bob ALL = (Tim) /bin/ls
If you want to specify that a user can run a command as root, you can either include root as the RunAs user or you can omit that part. So the following are identical in their end result:
Bob ALL = (root) /bin/ls
Bob ALL = /bin/ls
In place of ALL, you can specify a host if you want. For most cases in home situations or on small networks, ALL is fine since there aren’t many hosts. In larger networks, you may need to specify a network address or specific hostname.
Bob localhost = (Tim) /bin/ls
Bob 192.168.1.0/24 = (Tim) /bin/ls
To use the aliases we created earlier, you simply substitute that particular spot for the alias.
Bob ALL = (Tim) LDAP
This allows Bob to run the LDAP commands from the alias above as user Tim. You can also use the prefixes to specify groups, UIDs, etc., in place of the usernames or aliases.
%operator ALL = (Tim) LDAP
This says that everyone in the operator group can run LDAP commands as user Tim.
Another great security measure in sudo is the Tag specification. The most obvious uses of Tag specifications come from the PASSWD and NOPASSWD tags. These specify if the user needs to type in the RunAs user’s password to run the command. In cases where sudo is being used to allow specific root access for users, the NOPASSWD option is very useful. That way you can allow your users to run certain root commands without giving out the root password.
Bob ALL = NOPASSWD: /bin/ls
This says that Bob can run the ls command without typing root’s password in. You can combine both tags on one line as well:
Bob ALL = NOPASSWD: /bin/ls, PASSWD: LDAP
This specifies that Bob can run ls without the root password, but he can’t run LDAP commands without the root password. The default behavior is to require a password, so you’ll need to use NOPASSWD for any commands you want a user to execute without the password.
Sudo Defaults and Options
There are many default options you can set in the sudoers file as well. These options control the behavior of both how the users can use sudo and what sudo will do regardless of the user and command used. The two I’m going to cover here are how to set the logging options for sudo and how to mail the system administrator when a user fails sudo.
By default, sudo will log to syslog. This is fine in some cases, but in situations where many people will be using sudo or you need to have quick and easy access to view sudo history, having a separate log file is often a much better option. In sudo 1.6 and up, this can be easily set in the sudoers file. The logfile option allows you to specify the full path to the sudo log file. So in order to set the log file name, you would type this:
In similar fashion, you can set the mailing address to send an email to in the event that a user tries and fails to sudo. The default is for the user to get 3 tries, but you can also change that. To specify the mailing address:
Make sure you put quotes around the email address so that sudo does not accidentally interpret the @.
You can also specify several other mail options. The full list can be found in the sudo manual (see link below), but some of the highlights are mailsub, which sets the subject line of the email, mail_always, which sends an email every time sudo is used successfully as well as failures, and mail_no_perms, which sends an email if the invoking user is in the sudoers file but does not have access to the command he attempted to execute.
There are plenty of other options and specifications available in sudo. The ones listed here are just the most common and basic of sudo options. For a complete listing and instruction manual for your particular version of sudo, run this command on your system:
Also, you can check out the official sudo manual online at sudo’s website here.