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.

/etc/passwd:
root:x:0:0:root:/root:/bin/bash
root-bob:x:0:0:root:/root:/bin/bash
root-sally:x:0:0:root:/root:/bin/bash
root-vince:x:0:0:root:/root:/bin/bash

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:

~root/.ssh/authorized_keys:
command="/usr/local/bin/mycommand" ssh-dss fky7Dj7bGYxdHRYuHN ...

and the command would be invoked something like this:

$ ssh -l root -i private_key_name localhost

Kerberos ksu

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:

~ben/.k5login:
emma@EXAMPLE.COM

~ben/.k5users:
emma@EXAMPLE.COM /usr/local/bin/mycommand

and emma would invoke it as:

emma$ ksu ben -e mycommand

Like SSH, ksu also performs strong authentication prior to authorization. Kerberos is installed by default in Red Hat 8.0 but not included with SuSE 8.0.