Setting up sudo: Part 2

From: www.itworld.com


July 28, 2009 —


If when setting up your sudoers file using the visudo command, you define a group of users and a group of commands, you can assign the command set to the use set without having to add a separate line for each user. Over the long haul, this might save you a lot of work. You could turn something that looks like this repetitive list of users and the commands they are allowed to run as root:

jesse ALL = /usr/bin/kill, /usr/sbin/halt, /usr/sbin/shutdown, /usr/sbin/reboot
vail ALL = /usr/bin/kill, /usr/sbin/halt, /usr/sbin/shutdown, /usr/sbin/reboot
rafael ALL = /usr/bin/kill, /usr/sbin/halt, /usr/sbin/shutdown, /usr/sbin/reboot

into this:

User_Alias OPS = jesse, vail, rafael
Cmnd_Alias CONTROL = /usr/bin/kill, /usr/sbin/halt, /usr/sbin/shutdown, /usr/sbin/reboot
OPS ALL = OPS

Of course, that isn't convincingly better unless you have a lot more lines in your file and a number of users who share the same set of responsibilities. For example, you might want to assign a certain set of commands to your system administrators, another to your developers and a third set to your technical support staff.

An out-of-the-box sudoers file will generally only contain some comments detailing where each type of alias is supposed to be defined and maybe one "root ALL=(ALL) ALL" command that allows root to run any command using sudo. The fleshed out, customized file may be hundreds of lines long with both privilege settings and explanations about what was intended. User aliases, as the above example illustrates, contain the keyword "User_Alias" as the first item on the line and are then followed by the alias name ("OPS" in the above example) and the list of commands. Notice that full paths are specified with each command. We don't want just any command by that name that might appear on the system to be run with the authority of root.

# User alias specification
User_Alias SYSADMINS=shs,jdoe,allan
User_Alias DEVELOPERS=chris,peter,martha,sally
User_Alias WEBMASTERS=amy,sbob

Runas specifications determine the user or group that a command can be run as. For example, if we put the line "shs boson = (fred) /usr/bin/touch", then the user shs can issue the touch command as fred on boson. If we want to group runas users into an alias, we can do this:

Runas_Alias DB = oracle, postgres

The following line would then allow the user sbob to run any command on any system as oracle or postgres:

sbob ALL = (DB) ALL

You can group systems together in a Host-Alias in a similar manner. Just use the Host_Alias keyword, provide a name for your system grouping and then list the group members.

Host_Alias DEVBOXES = mercury, venus, earth, mars, jupiter, saturn, uranus, neptune

Then, if you want sbob to have database privileges on only the development servers, you can use this command:

sbob DEVBOXES = (DB) ALL

Command aliases are defined with the keyword Cmnd_Alias, the name and a list of commands. These should be added in logical groupings. For example, this alias makes a lot of sense since it groups the commands that deal with passwords and other user parameters:

Cmnd_Alias VIPW = /usr/sbin/vipw, /usr/bin/passwd, /usr/bin/chsh, \
/usr/bin/chfn

Also notice how the continuation character allows alias definitions to spans lines.

User specifications can begin with a specific user name (e.g., shs), an alias (e.g., OPS), a netgroup (e.g., +netmgrs) or system group (e.g., %wheel). For example:

+netmgrs DEPTBOXES = ALL

Once you define a set of aliases that works for your site, you will find that maintaining the sudoers file becomes much easier, especially when many users and systems are involved.

The sudoers file also includes a section that is intended to allow sudo defaults to be changed. For example, you might decide not to lecture (i.e., forgo displaying a short blurb about the use of xxxxx) or can specify a file containing an alternate lecture. The sample command below tells sudo not to lecture the developers (anyone included in the DEVELOPERS user alias).

# Defaults specification
Defaults:DEVELOPERS !lecture

The sudoers file can become fairly complicated, but if you set it up carefully, it can provide a reliable degree of control over who does what on your servers. Just remember to update it as people come and go and change positions. It's an easy thing to overlook if you set it up and then forget about it.