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.

Alternatives to the Superuser Other operating systems—including Multics—obviate the superuser flaw by compartmentalizing the many system privileges that Unix bestows on the root user. Indeed, attempts to design a "secure" Unix (one that meets U.S. Government definitions of highly trusted systems) have adopted this same strategy of dividing superuser privileges into many different categories. Unfortunately, attempts at compartmentalization often fail. For example, Digital's VAX/VMS operating system divided system privileges into many different classifications. But many of these privileges could be used by a persistent person to establish the others. For example, an attacker who achieves "physical I/O access" can modify the operating system's database to grant himself any other privilege that he desires. Thus, instead of a single catastrophic failure in security, we have a cascading series of smaller failures leading to the same end result. For compartmentalization to be successful, it must be carefully thought out.

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!)

Table 5-2. Some capabilities in Linux 2.4.19

Capability	Description
CAP_CHOWN	Can change file owner and group
CAP_FOWNER	Can override file restrictions based on file owner ID
CAP_FSETIDCAP_SETUIDCAP_SETGID	Can override requirements for setting SUID and SGID bits on files
CAP_KILL	Can send signals to any process
CAP_LINUX_IMMUTABLE	Can change the immutable or append-only attributes on files
CAP_NET_BIND_SERVICE	Can bind to TCP/UDP ports below 1024
CAP_NET_BROADCAST	Can transmit broadcasts
CAP_NET_ADMIN	Can configure interfaces, bind addresses, modify routing tables and packet filters, and otherwise manage networking
CAP_NET_RAW	Can use raw and packet sockets
CAP_IPC_LOCK	Can lock shared memory
CAP_IPC_OWNER	Can override IPC ownership checks
CAP_SYS_MODULE	Can load and remove kernel modules
CAP_SYS_CHROOT	Can use chroot( )
CAP_SYS_PTRACE	Can ptrace( ) any process
CAP_SYS_PACCT	Can enable, disable, or configure process accounting
CAP_SYS_ADMIN	Can configure disk quotas, configure kernel logging, set hostnames, mount and unmount filesystems, enable and disable swap, tune disk devices, access system bios, set up serial ports, and many other things
CAP_SYS_BOOT	Can use reboot( )
CAP_SYS_NICE	Can change process priorities and scheduling
CAP_SYS_RESOURCE	Can set or override limits on resources, quotas, reserved filesystem space, and other things
CAP_SYS_TIME	Can manipulate system clock
CAP_SYS_TTY_CONFIG	Can configure tty devices
CAP_SETPCAP	Can transfer or remove capabilities from any other process

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.