Linux Security Cookbook [Electronic resources] نسخه متنی

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:

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.

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]

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.

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

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.