5.2 The Superuser (root)
Almost
every Unix system comes with a special user in the
/etc/passwd file with a UID of 0. This user is
known as the superuser and is normally given
the username root. The password for the
root account is usually called simply the
"root
password."
The root account is the identity used by the
operating system itself to accomplish its basic functions, such as
logging users in and out of the system, recording accounting
information, and managing input/output devices. For this reason, the
superuser exerts nearly complete control over the operating system:
nearly all security restrictions are bypassed for any program that is
run by the root user, and most of the checks and
warnings are turned off.
5.2.1 What the Superuser Can Do
Any process that has an
effective UID of 0 (see
Section 5.3.1
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 Section B.1.3.3).
Send any signal to any process (see
Signals).
Alter "hard limits" for maximum CPU
time as well as maximum file, data segment, stack segment, and core
file sizes (see Chapter 23).
Turn accounting and auditing on and off (see Chapter 21).
Bypass login restrictions prior to shutdown. (Note that this may not
be possible if you have configured your system so that the superuser
cannot log into terminals.)
Change his process UID to that of any other user on the system.
Log out all users and prevent new logins.
- Device control
-
Access any working device.
Shut down or reboot 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).
Reconfigure the network.
Put the network interface into "promiscuous
mode" and examine all packets on the network
(possible only with certain kinds of networks and network
interfaces).
- Filesystem control
-
Read, modify, or delete any file or program on the system (see Chapter 6).
Run any program.
Change a disk's electronic label.
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.
5.2.2 What the Superuser Can't Do
Despite all of the powers listed in the
previous section, there are some things that the superuser
can't do, including:
Make a change to a filesystem that is mounted read-only. (However,
the superuser can make changes directly to the raw device, or can
unmount a read-only filesystem and remount it read/write, provided
that the media is not physically write-protected.)
Unmount a filesystem that contains open files, or one in which some
running process has set its current directory.
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 shadow password 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.
5.2.3 Any Username Can Be a Superuser
As we noted
in Section 5.1,
any account that 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:x:0:1:Operator:/:/bin/ksh
beth:x:0:101:Beth Cousineau:/u/beth:/bin/csh
rachel:x:181:181:Rachel Cohen:/u/rachel:/bin/ksh
You should immediately be suspicious of accounts on your system that
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.
5.2.4 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 the superuser.
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:
Storing sensitive files on removable media, and mounting the media
only when you need to access the files. An attacker who gains
superuser privileges while the media are unmounted will not have
access to critical files.
Encrypting 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 7.) Best practice is to encrypt with a
passphrase other than your login password, which an attacker might
capture.
Mounting disks read-only when possible.
Taking advantage of filesystem features like immutable and
append-only files if your system supports them.
Keeping your backups of the system current. This practice is
discussed further in Chapter 16.
There are many other defenses, too, and we'll
continue to present them in this chapter and throughout this
book.
|