Eliminating Root with Sudo
by Michael W. Lucas08/29/2002
While proper implementation of groups can help reduce the need for the root password, at times, users must absolutely run commands as another user (usually root). As the system administrator, you're stuck between deciding to hand out the root password or doing everything for your users. sudo provides a third way, one that can help solve this dilemma. It's a tricky program, however, and needs some care in implementation. sudo
is integrated into OpenBSD, and is an add-on package for just about
every other Unix-like operating system out there.
sudo is a setuid root wrapper that implements fine-grained access
control for commands that need to be run as root. It takes the
command you want to run and compares it to its internal list of
permissions. If sudo's permissions allow that particular user to run
that command, sudo runs that command for you, with its privileges. As
root can run commands as any user, sudo can execute commands as any
arbitrary system user.
With proper setup, the system administrator can allow any user to run
any command as any other user. sudo is a very powerful tool, and can
be configured to allow or deny almost any set of commands. As a
result of this flexibility, the documentation tends to scare off new
users. We're going to do a basic sudo setup that will cover almost
all uses, but you should be aware that many more combinations are
possible, and are documented in sudo(8) and sudoers(5).
Other than the obvious fine-grained access control sudo provides,
there are a few other benefits to using sudo. One of the biggest
advantages is the command logging. Every sudo command is logged,
making it very easy to track who made what changes. And once you have
sudo configured correctly, you can change the root password and not
give it to anyone. Nobody should need the root password if they have
the correct sudo permissions, after all! Reducing the number of
people who have the root password can help improve security. Finally,
a single sudo configuration file can be used on all of these systems,
vastly easing administrator overhead.
|
Also in Big Scary Daemons: Running Commercial Linux Software on FreeBSD Building Detailed Network Reports with Netflow Visualizing Network Traffic with Netflow and FlowScan |
The most overwhelmingly common disadvantage to sudo is that users and
junior administrators don't like it. If people have traditionally had
root access on a system, they will perceive that they're losing
something when you implement sudo. They key to overcoming this is to
make sure that people have the ability to do their jobs. If users
think that they need the root password to perform other tasks, then
your need to settle just who is responsible for what. These users may
have been taking extra duties upon themselves, rather than troubling
you with jobs that you should do.
A faulty sudo setup can create security holes. A thoughtless
configuration will create holes in the system that a clever user can
use to actually become root. This problem is best dealt with by a
combination of careful configuration and administrative policy.
sudo has three pieces. The first is the actual sudo(8) command, the
setuid root wrapper that users will actually use. There's also sudo's
configuration file, /etc/sudoers. This file is sudo's permissions
table, saying who may run what commands as which user, and is fully
documented in sudoers(5). Finally, the visudo(8) command allows
administrators to edit the sudoers file without risking locking
themselves out of the system. We'll consider each component in turn:
visudo, the sudoers file, and sudo itself.
If the syntax in your sudoers file is incorrect, sudo will not run.
If you're relying on sudo to provide access to the sudoers file, and
you corrupt the sudoers file, you can lock yourself out of root-level
activities on the system and be unable to correct your error. This is
bad. visudo(8) provides some protection against this sort of error.
|
Related Reading Essential System Administration |
Much like vipw(8), visudo(8) locks the file so only one person can
edit the configuration file at a time. It then opens the sudo
configuration file in an editor (vi(1) by default, but it respects the
$EDITOR environment variable). When you exit the editor, visudo
parses the file and confirms that there are no sudo syntax errors.
This is not a guarantee that the configuration will do what you want,
merely a confirmation that the file is actually a valid. visudo(8)
will accept a configuration file that says "nobody may do anything via
sudo" if the rules are properly formatted.
