Chapter 5. Authorization Controls

Authorization
means deciding what a user may or may not do on a computer: for
example, reading particular files, running particular programs, or
connecting to particular network ports. Typically, permission is
granted based on a credential such as a password or cryptographic
key.

The
superuser root, with uid
0, has full control over every file, directory, port, and dust
particle on the computer. Therefore, your big, security-related
authorization questions are:

Who has root privileges on my computer?

How are these privileges bestowed?

Most commonly, anyone knowing your root
password
has superuser powers, which are granted with the
su command:

$ su
Password: *******
#

This technique is probably fine for a single person with one
computer. But if you're a superuser on multiple
machines, or if you have several superusers, things get more
complicated. What if you want to give temporary or limited root
privileges to a user? What if one of your superusers goes berserk:
can you revoke his root privileges without impacting other
superusers? If these tasks seem inconvenient or difficult, your
system might benefit from additional infrastructure for
authorization.

Here are some common infrastructures and our opinions of them:

Sharing the root password

This is conceptually the simplest, but giving every superuser full
access to everything is risky. Also, to revoke a rogue
superuser's access you must change the root
password, which affects all other superusers. Consider a finer
grained approach. When cooking a hamburger, after all, a flamethrower
will work but a simple toaster oven might be
more appropriate.

Multiple root accounts

Make
several accounts with uid 0 and gid
0, but different usernames and passwords.

We do not recommend this method. It provides finer control than
sharing the root password, but it's less powerful
than the later methods we'll describe. Plus
you'll break some common scripts that check for the
literal username "root" before
proceeding. See our recipe for locating superuser accounts so you can
replace them and use another method. [Recipe 9.4]

sudo

Most of
this chapter is devoted to sudo recipes. This
package has a system-wide configuration file,
/etc/sudoers, that specifies precisely which Linux
commands may be invoked by given users on particular hosts with
specific privileges. For example, the sudoers
entry:

/etc/sudoers:
smith myhost = (root) /usr/local/bin/mycommand

means that user smith may invoke the command
/usr/local/bin/mycommand on host myhost as user root. User smith can now
successfully invoke this program by:

smith$ sudo -u root /usr/local/bin/mycommand

sudo lets you easily give out and quickly revoke
root privileges without revealing the root password. (Users
authenticate with their own passwords.) It also supports
logging so you can discover who ran
which programs via sudo. On the down side,
sudo turns an ordinary user password into a
(possibly limited) root password. And you must configure it
carefully, disallowing arbitrary root commands and arbitrary argument
lists, or else you can open holes in your system.

SSH

The
Secure
Shell can authenticate superusers by public key and let them execute
root commands locally or remotely. Additionally, restricted
privileges can be granted using SSH forced commands. The previous
sudoers example could be achieved by SSH as:

If your environment has a Kerberos infrastructure, you can use
ksu, Kerberized su, for
authorization. Like sudo, ksu
checks a configuration file to make authorization decisions, but the
file is per user rather than per system. That is, if user emma wants
to invoke a command as user ben, then ben must grant this permission
via configuration files in his account: