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.^[61] 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.

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.

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:

At security level 2, the following restriction is added:

At security level 3, the following restriction is added:

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.

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.