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.

Setting up sudo

From: www.itworld.com


July 22, 2009 —


One clear benefit of sudo is that users don't have to remember another password to be able to run commands as root. Besides, you probably don't want them to have general root access. It's also extremely handy when you want someone to have temporary root access; you don't even have to provide them with the password. Just enable them to "sudo su" and they'll acquire root access just by using this command and their own password.

You can give full root access to a system without providing the root password by using a record like this in the sudoers file:

visadmin ALL=/usr/bin/su

You would add a line such as this to the sudoers file using the visudo command.

For more general use, you can specify the commands that you want particular users to be able to run as root or not be able to run as root. It's far easier, however, and more secure to list the commands that you want your users to run with the authority of root, rather than those you want to block them from using. Blocking can be easy to defeat (e.g., if they create a symbolic link to a command they're not allowed to execute) as shown in the example below. Besides, it's hard to consider all the possible ways around the controls or remember to update the sudoers file after you have added new tools.

boson> sudo date
Password:
Sorry, user shs is not allowed to execute '/usr/bin/date' as root on boson.
Jul 22 15:24:24 boson sudo: [ID 702911 local2.alert] shs : command not
allowed ; TTY=pts/2 ; PWD=/export/home/shs ; USER=root ; COMMAND=/usr/bin/date
boson> which date
/usr/bin/date
boson> ln -s /usr/bin/date dt
boson> ls -l dt
lrwxrwxrwx 1 shs other 13 Jul 22 10:22 dt -> /usr/bin/date
boson> sudo ./dt
Password:
Wed Jul 22 10:23:38 EDT 2009

Sudo access rules are simple in structure, but a little dense, especially when they contain a whole bunch of ALLs like "SYSADMINS ALL = ALL" or even "ALL ALL=(ALL) ALL" and you're not sure what each of these "ALLs" is meant to accomplish.

ALL is a placeholder. Its basic definition is "match everything". If you put ALL in a field which is meant to identify a user who is being given the ability to run certain commands as root, ALL means all users. If ALL is used in the command field, it means all commands. The "ALL ALL=(ALL) ALL" specification would then mean that everyone can do everything as root. Not a good setting! But maybe an OK example.

ALL ALL=(ALL) ALL
^ ^ ^ ^
| | | |
1 2 3 4

1 = all users
2 = all terminals
3 = acting as any user
4 = all commands

The line "shs ALL=(ALL) ALL" would give all privileges to a user "shs".

If the third ALL in this command structure is puzzling, consider that you can use sudo to run commands for accounts other than root as is shown in the example below.

boson> sudo -u fred touch /tmp/x
-rw-r--r-- 1 fred other 0 Jul 22 11:03 /tmp/x

If the line in the sudoers file was "shs ALL=(eric) /usr/bin/touch", shs could only issue the touch command via sudo as the user eric.

The first column in the sudoers file represents users or aliases. It might be a individual username, an alias for a group of users (e.g., SYSADMINS) defined earlier in the file or a representation of all users (%users). It might an alias for a group of commands, systems or a "run as" alias.

Records in the sudoers file are applied in the order in which they are listed. If multiple lines apply to a particular sudo command, the one listed last is the one that is used. So, if one line says that you can issue a command as root and the next says you can't, you can't.

Next week, we'll look at some examples of sudoers files and how they work.