244 Security Security Is Not a Line Printer Unix implements computer security as it implements any other operating system service. A collection of text files (such as .rhosts and /etc/groups), which are edited with the standard Unix editor, control the security config- uration. Security is thus enforced by a combination of small programs— each of which allegedly do one function well—and a few tricks in the oper- ating system’s kernel to enforce some sort of overall policy. Combining configuration files and small utility programs, which works passably well for controlling a line printer, fails when applied to system security. Security is not a line printer: for computer security to work, all aspects of the computer’s operating system must be security aware. Because Unix lacks a uniform policy, every executable program, every configuration file, and every start-up script become a critical point. A sin- gle error, a misplaced comma, a wrong setting on a file’s permissions enable catastrophic failures of the system’s entire security apparatus. Unix’s “programmer tools” philosophy empowers combinations of rela- tively benign security flaws to metamorphose into complicated systems for breaking security. The individual elements can even be booby-trapped. As a result, every piece of the operating system must be examined by itself and in concert with every other piece to ensure freedom from security viola- tions. A “securely run Unix system” is merely an accident waiting to happen. Put another way, the only secure Unix system is one with the power turned off. Holes in the Armor Two fundamental design flaws prevent Unix from being secure. First, Unix stores security information about the computer inside the computer itself, without encryption or other mathematical protections. It’s like leaving the keys to your safe sitting on your desk: as soon as an attacker breaks through the Unix front door, he’s compromised the entire system. Second, the Unix superuser concept is a fundamental security weakness. Nearly all Unix systems come equipped with a special user, called root, that circum- vents all security checks and has free and total reign of the system. The superuser may delete any file, modify any programs, or change any user’s password without an audit trail being left behind.

Holes in the Armor 245 Superuser: The Superflaw All multiuser operating systems need privileged accounts. Virtually all multiuser operating systems other than Unix apportion privilege according to need. Unix’s “Superuser” is all-or-nothing. An administrator who can change people’s passwords must also, by design, be able to wipe out every file on the system. That high school kid you’ve hired to do backups might accidentally (or intentionally) leave your system open to attack. Many Unix programs and utilities require Superuser privileges. Complex and useful programs need to create files or write in directories to which the user of the program does not have access. To ensure security, programs that run as superuser must be carefully scrutinized to ensure that they exhibit no unintended side effects and have no holes that could be exploited to gain unauthorized superuser access. Unfortunately, this secu- rity audit procedure is rarely performed (most third-party software vendors, for example, are unwilling to disclose their sourcecode to their customers, so these companies couldn’t even conduct an audit if they wanted). The Problem with SUID The Unix concept called SUID, or setuid, raises as many security problems as the superuser concept does. SUID is a built-in security hole that provides a way for regular users to run commands that require special privileges to operate. When run, an SUID program assumes the privileges of the person who installed the program, rather than the person who is running the pro- gram. Most SUID programs are installed SUID root, so they run with supe- ruser privileges. The designers of the Unix operating system would have us believe that SUID is a fundamental requirement of an advanced operating system. The most common example given is /bin/passwd, the Unix program that lets users change their passwords. The /bin/passwd program changes a user’s password by modifying the contents of the file /etc/passwd. Ordinary users can’t be allowed to directly modify /etc/passwd because then they could change each other's passwords. The /bin/passwd program, which is run by mere users, assumes superuser privileges when run and is constructed to change only the password of the user running it and nobody else’s. Unfortunately, while /bin/passwd is running as superuser, it doesn’t just have permission to modify the file /etc/passwd: it has permission to mod- ify any file, indeed, do anything it wants. (After all, it’s running as root, with no security checks). If it can be subverted while it is running—for example, if it can be convinced to create a subshell—then the attacking user can inherit these superuser privileges to control the system.