Software Development

Delegate privileges to users with sudo

Vincent Danen offers a quick primer about sudo and how you can use it to delegate different privileges to users.

One of my favourite tools is sudo, a program that many users will be familiar with. Both Ubuntu and OS X popularized sudo by making efficient and default use of the program. Sudo allows regular users to perform commands as other users.

Some lax defaults, such as allowing certain users to perform any commands as root, have become the norm, but sudo offers much more than that. Granted, for a single-user system, perhaps allowing all commands to be executed as root makes sense; if nothing else, it prevents users from having to run with a full root shell and forces them to pause and think about what they're doing when sudo prompts for a password before performing the requested action.

The nice thing about sudo is that it offers an audit trail, and for that reason it makes sense to use sudo instead of simply using su to become root. Certainly, using su has its advantages if a number of things need to be done as root. In that instance, I would argue that using sudo su - instead of su- makes more sense; for one, it allows /bin/su to be stripped of the suid bit (turning it from a suid root program to a regular program executable only by root), and it provides an audit trail so that you can see, not only when su was called to become root, but also by whom.

Having said that, sudo offers a number of means to further delegate tasks that users need to perform as root. For instance, if a user needs to be able to install packages on a system, but does not require full root privileges, instead of giving them those full privileges, simply delegate with sudo. Edit /etc/sudoers with visudo (which performs syntax checking) and add:

Cmnd_Alias    SCRIPT = /usr/local/bin/script, /usr/local/bin/script2

%admin        ALL = (qa) NOPASSWD: SCRIPT

This example illustrates a few different things that can be done with sudo. The first is the Cmnd_Alias command, which allows us to assign aliases to commands. In this case, the SCRIPT alias is linked to two commands: /usr/local/bin/script and /usr/local/bin/script2. Now, instead of referring to both scripts, only the alias is needed.

The second line illustrates a number of features. The first is group assignment; by using %admin the following commands are applicable to any user in the "admin" group. To refer to a specific user, use their username -- groups are always prefixed with the % character.

The ALL indicates that this command is available on all hosts. Using NOPASSWD tells sudo that the user's password is not required, otherwise the user would have to authenticate to sudo with their password. Finally, the (qa) SCRIPT indicates that the commands associated to the SCRIPT alias may be executed, but only as the user qa. Note that this means those scripts will be run with the privileges of the qa user rather than root.

In short, that line indicates that any users in the admin group, on any host, may execute the scripts /usr/local/bin/script and /usr/local/bin/script2 as user qa, without having to enter their password.

This small sampling shows the flexibility of allowing sudo to delegate privileges to users. Instead of providing blanket all-or-nothing access, sudo can fine-tune privileges so that those administrators dealing with Web services may have root privileges to do things such as edit Apache configuration files, restart the Apache service, and possibly interact with a database such as MySQL, all with root (or with another user) privileges; others have regular user permissions to the rest of the system.

Get the PDF version of this tip here.

Delivered each Tuesday, TechRepublic's free Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

4 comments
bond.masuda
bond.masuda

as useful as sudo is, there are many pitfalls in its use that administrators who are serious about security need to be aware of. a classic example might be delegating maintenance of a root owned file to a non-root user: user_bob ALL = (root) NOPASSWD: /bin/vi /etc/root_owned_file This might seem innocent enough; you allow the 'user_bob' account to edit the file /etc/root_owned_file. In order to do this, you must allow user_bob to run 'vi' as root. You might think that this doesn't allow user_bob to do anything else. But the vi editor allows shell escapes, and since it's running as root, whatever command it runs will run as root. In the vi editor, if you run the command :!/bin/sh, you end up with a root shell. user_bob now has no restrictions. Another such example might be, say you want to allow certain operators to be able to view your /etc/shadow file in order to help users and verify that a password has been set or not: operator ALL=(root) NOPASSWD: /bin/more /etc/shadow The problem here? Well, by hitting 'v' while more is running, it can invoke vi to edit the file. It's bad enough that they can edit the /etc/shadow file, but once again, they can also invoke a root shell with :!/bin/sh In addition to choosing the commands you allow carefully, similar cautions need to be made when dealing with pattern matching paths, or trying to exclude commands from 'ALL'. For example, you might have database files in /usr/local/dbfiles that you want to allow DBAs to run some commmands on. Since you think that all the files in the 'dbfiles' directory belong to the DBAs anyway, you might try to use the path: /usr/local/dbfiles/* But then you would allow those DBAs to run their tools with additional privileges (perhaps root?) on the file: /usr/local/dbfiles/../../../etc/shadow As a general best practice, never allow the commands that you are allowing to be writable by the user you are allowing to escalate privileges. For example, you might get a request from user 'george' like: "I installed a tool in /home/george/bin/mytool, but it only works if i can run it as root. Can you allow me to run it with sudo?" The answer you want to give is "no", but you can allow the user to run that command if you can copy the 'mytool' to a root owned directory, and change ownership of the tool to 'root' with the appropriate permissions. Otherwise, 'george' can simply later replace 'mytool' with a script that looks like: #!/bin/sh /bin/bash Bottom line is, use sudo with caution. It's not difficult to fall into some of the pitfalls.

scarville
scarville

%admin ALL = NOPASSWD: (qa) SCRIPT Should be: %admin ALL = (qa) NOPASSWD: SCRIPT

vdanen
vdanen

Yup, you're absolutely right. I don't like using wildcards with sudo for the reasons you mentioned above. And making use of rvim (restricted vim) are better than using vim directly, due to the shell escapes. For more... well.. I don't know why you would need to give anyone other than root access to /etc/shadow (a poor example in my opinion), but the point is well taken. Programs with shell escapes should be run in a restricted mode (or use an alternative with such a mode).

Selena Frye
Selena Frye

Yes, thank you -- that was an error. It has been corrected in the post.

Editor's Picks