5.4 Restrictions on the Superuser

Because the superuser account is occasionally compromised—for example, by somebody sharing the superuser password with a friend—there have been numerous attempts to limit the availability and the power of the Unix superuser account.

5.4.1 Secure Terminals: Limiting Where the Superuser Can Log In

Most versions of Unix allow you to configure certain terminals so that users can't log in as the superuser from the login: prompt. Anyone who wishes to have superuser privileges must first log in as himself and then su to root. This feature makes tracking who is using the root account easier because the su command logs the username of the person who runs it and the time that it was run.^[13] Unix also requires that the root user's password be provided when booting in single-user mode if the console is not listed as being secure.

^[13] Unless you configure your syslog system so that this log is kept on a remote machine, the person who uses the su command can delete the logfile after successfully becoming root. For information on configuring the syslog system, see Chapter 21.

Secure consoles add to overall system security because they force people to know two passwords to gain superuser access to the system. Network virtual terminals should not be listed as secure to prevent users from logging into the root account remotely using telnet. (Of course, telnet should also be disabled, which it isn't in some environments.) The Secure Shell server ignores the terminal security attribute, but it has its own directive (PermitRootLogin in sshd_config) that controls whether users may log in as root remotely.

On BSD-derived systems, terminal security is specified in the /etc/ttys file. In this excerpt from the file, the tty00 terminal is secure and the tty01 terminal is not:

tty00   "/usr/libexec/getty std.9600"   unknown on secure
tty01   "/usr/libexec/getty std.9600"   unknown on

On System V-derived systems, terminal security is specified in the file /etc/securetty. This file specifies that tty1 and tty2 are secure:

# more /etc/securetty 
tty1
tty2
#

In general, most Unix systems today are configured so that the superuser can log in with the root account on the system console, but not on other terminals.

Even if your system allows users to log directly into the root account, we recommend that you institute rules that require users to first log into their own accounts and then use the su command.

5.4.2 BSD Kernel Security Levels

FreeBSD, Mac OS X, and other operating systems have kernel security levels, which can be used to significantly reduce the power that the system allots to the root user. Using kernel security levels, you can decrease the chances that an attacker who gains root access to your computer will be able to hide this fact in your logfiles.

The kernel security level starts at 0; it can be raised as part of the system startup, but never lowered. The secure level is set with the sysctl command:

sysctl kern.securelevel=1

Level 1 is used for secure mode. Level 2 is used for "very secure" mode. Level 3 is defined as the "really-really secure mode."

At security level 1, the following restrictions are in place:

• Write access to the raw disk partitions is prohibited. (This forces all changes to the disk to go through the filesystem.)

• Raw access to the SCSI bus controller is prohibited.

• Files that have the immutable flag set cannot be changed. Files that have the append-only bit set can only be appended to, and not otherwise modified or deleted.

• The contents of IP packets cannot be logged.

• Raw I/O to the system console is prohibited.

• Raw writes to system memory or I/O device controllers from user programs are prohibited.

• Some access is denied to the Linux /proc filesystem.

• Additional kernel modules cannot be loaded.

• The system clock cannot be set backwards. In addition, it cannot be set forward more than a maximum of one second, and it can be set forward only once per second (effectively, the clock can be pushed at most to double time).

At security level 2, the following restriction is added:

• Reads from raw disk partitions are not permitted.

At security level 3, the following restriction is added:

• Changes to the IP filter are not permitted.

This list is not comprehensive.

Overall, setting the secure level to 1 or 2 enables you to increase the overall security of a Unix system; it also makes the system dramatically harder to administer. If you need to take an action that's prohibited by the current security level, you must reboot the system to do so. Furthermore, the restrictions placed on the root user at higher secure levels may not be sufficient; it may be possible, given enough persistence, for a determined attacker to circumvent the extra security that the secure level system provides. In this regard, setting the level higher may create a false sense of security that lulls the administrator into failing to put in the proper safeguards. Nevertheless, if you can run your system at a secure level higher than 0 without needing to constantly reboot it, it's probably worthwhile to do so.

5.4.3 Linux Capabilities

Another mechanism for limiting the power of the superuser is the Linux capabilities system, invented on other operating systems five decades ago and included with the Linux 2.4 kernel. Some other high-security Unix systems and security add-ons to Unix have used capabilities for years, and the POSIX committee drafted a standard (POSIX 1003.1e) but later withdrew it.

The Linux capabilities system allows certain privileged tasks to be restricted to processes that have a specific "capability." This capability can be used, transferred to other processes, or given up. Once a process gives up a capability, it cannot regain that capability unless it gets a copy of the capability from another process that was similarly endowed. At startup, the init process generates all of the capabilities that the operating system requires for its use. As processes start their operations, they shed unneeded capabilities. In this manner, compromising one of these processes does not compromise other aspects of the operating system, even if the compromised process is running as root.

Some of the capabilities that a program can give up in the Linux 2.4.19 kernel are shown in Table 5-2. (This table also provides a nice illustration of the power of the superuser!)

Unfortunately, at the time this edition is being written, few Linux systems are designed to take advantage of the kernel capabilities and few system programs have been written to shed capabilities.