4.2.1.1 Any username can be the superuser

As we noted in the section Section 4.1, "Users and Groups " Although every UNIX user has a username of up to eight characters long, inside the computer UNIX represents each user by a single number: the user identifier (UID). Usually, the UNIX system administrator gives every user on the computer a different UID. UNIX also uses special usernames for a variety of system functions. As with usernames associated with human users, system usernames usually have their own UIDs as well. Here are some common "users" on various versions of UNIX:">" earlier in this chapter, any account which has a UID of 0 has superuser privileges. The username root is merely a convention. Thus, in the following sample /etc/passwd file, both root and beth can execute commands without any security checks:

root:zPDeHbougaPpA:0:1:Operator:/:/bin/ksh
beth:58FJ32JK.fj3j:0:101:Beth Cousineau:/u/beth:/bin/csh
rachel:eH5/.mj7NB3dx:181:100:Rachel Cohen:/u/rachel:/bin/ksh

You should immediately be suspicious of accounts on your system which have a UID of 0 that you did not install; accounts such as these are frequently added by people who break into computers so that they will have a simple way of obtaining superuser access in the future.

4.2.1.2 Superuser is not for casual use

The root account is not an account designed for the personal use of the system administrator. Because all security checks are turned off for the superuser, a typing error could easily trash the entire system.

The UNIX system administrator will frequently have to become the superuser to perform various system administration tasks. This change in status can be completed using the su command (discussed later in this chapter) to spawn a privileged shell. Extreme caution must be exercised when operating with superuser capabilities. When the need for superuser access has ended, the system administrator should exit from the privileged shell.

NOTE: Many 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 or herself 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.[7] The feature also adds to overall system security, because people will need to know two passwords to gain superuser access to your system.

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. We describe this technique in the section called Section 4.3.6, "Restricting su " later in this chapter.

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.

4.2.1.3 What the superuser can do

Any process that has an effective UID of 0 (see "Real and Effective User IDs" later in this chapter) runs as the superuser - that is, any process with a UID of 0 runs without security checks and is allowed to do almost anything. Normal security checks and constraints are ignored for the superuser, although most systems do audit and log some of the superuser's actions.

Some of the things that the superuser can do include:

Process Control:

• Change the nice value of any process (see the section "Process priority and niceness" in Appendix C, UNIX Processes ).

• Send any signal to any process (see "Signals" in Appendix C ).

• Alter "hard limits" for maximum CPU time as well as maximum file, data segment, stack segment, and core file sizes (see Chapter 11, Protecting Against Programmed Threats ).

• Turn accounting on and off (see Chapter 10 ).

• Bypass login restrictions prior to shutdown. (Note: this may not be possible if you have configured your system so that the superuser cannot log into terminals.)

• Change his or her process UID to that of any other user on the system.

• Log out all users and shutdown or reboot the system.

Device Control:

• Access any working device.

• Shut down the computer.

• Set the date and time.

• Read or modify any memory location.

• Create new devices (anywhere in the filesystem) with the mknod command.

Network Control:

• Run network services on "trusted" ports (see Chapter 17, TCP/IP Services ).

• Reconfigure the network.

• Put the network interface into "promiscuous mode" and examine all packets on the network (possible only with some kinds of network interfaces).

Filesystem Control:

• Read, modify, or delete any file or program on the system (see Chapter 5, The UNIX Filesystem ).

• Run any program.[8]

  [8] If a program has a file mode of 000, root must set the execute bit of the program with the chmod() system call before the program can be run, although shell scripts can be run by feeding their input directly into /bin/sh.

• Change a disk's electronic label.[9]

  [9] Usually stored on the first 16 blocks of a hard disk or floppy disk formatted with the UNIX filesystem.

• Mount and unmount filesystems.

• Add, remove, or change user accounts.

• Enable or disable quotas and accounting.

• Use the chroot() system call, which changes a process's view of the filesystem root directory.

• Write to the disk after it is "100 percent" full. (The Berkeley Fast Filesystem and the Linux ext2 File System both allow the reservation of some minfree amount of the disk. Normally, a report that a disk is 100% full implies that there is still 10% left. Although this space can be used by the superuser, it shouldn't be: filesystems run faster when their disks are not completely filled.)

4.2.1.4 What the superuser can't do

Despite all of the powers listed above, there are some things that the superuser can't do, including:

• Make a change to a filesystem that is mounted read-only. (However, the su-peruser can make changes directly to the raw device, or unmount a read-only filesystem and remount it read/write, provided that the media is not physically write-protected.)

• Unmount a filesystem which contains open files, or in which some running process has set its current directory.[10]

  [10] Many BSD variants (including NetBSD and FreeBSD) provide an -f option to umount , which forcibly unmounts a busy filesystem.

• Write directly to a directory, or create a hard link to a directory (although these operations are allowed on some UNIX systems).

• Decrypt the passwords stored in the /etc/passwd file, although the superuser can modify the /bin/login and su system programs to record passwords when they are typed. The superuser can also use the passwd command to change the password of any account.

• Terminate a process that has entered a wait state inside the kernel, although the superuser can shut down the computer, effectively killing all processes.

4.2.1.5 The problem with the superuser

The superuser is the main security weakness in the UNIX operating system. Because the superuser can do anything, after a person gains superuser privileges - for example, by learning the root password and logging in as root  - that person can do virtually anything to the system. This explains why most attackers who break into UNIX systems try to become superusers.

Most UNIX security holes that have been discovered are of the kind that allow regular users to obtain superuser privileges. Thus, most UNIX security holes result in a catastrophic bypass of the operating system's security mechanisms. After a flaw is discovered and exploited, the entire computer is compromised.

There are a number of techniques for minimizing the impact of such system compromises, including:

• Store your files on removable media, so that an attacker who gains superuser privileges will still not have access to critical files.

• Encrypt your files. Being the superuser grants privileges only on the UNIX system; it does not magically grant the mathematical prowess necessary to decrypt a well-coded file or the necessary clairvoyance to divine encryption keys. (Encryption is discussed in Chapter 6, Cryptography .)

• Mount disks read-only when possible.

• Keep your backups of the system current. This practice is discussed further in Chapter 7, Backups .

There are many other defenses, too, and we'll continue to present them throughout this book.

Other operating systems - including Multics - obviate the superuser flaw by compartmentalizing the many system privileges which 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 divides system privileges into many different classifications. But many of these privileges can be used by a persistent person to establish the others: 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.