kernelthread.com

A Taste of Computer Security

© Amit Singh. All Rights Reserved. Written in June 2004


Traditional Unix Security

Perhaps the most important achievement of UNIX is to demonstrate that a powerful operating system for interactive use need not be expensive either in equipment or in human effort: UNIX can run on hardware costing as little as $40,000, and less than two man-years were spent on the main system software.

The UNIX Time-Sharing System (1974)
Dennis M. Ritchie and Ken Thompson

UNIX was born in 1969. Although computer security is an age-old subject, the UNIX system itself was not created with security in mind. In a 1979 document titled On the Security of UNIX, Dennis Ritchie said:

"The first fact to face is that UNIX was not developed with security, in any realistic sense, in mind; this fact alone guarantees a vast number of holes."

Now, although the creators of UNIX did not expect it to become so successful, it did, and security became progressively important. Numerous mechanisms for providing security have been incorporated into Unix over the years, through component redesign, and often through retrofitting.

The earliest versions of UNIX had the concept of the super-user, and supported file permissions. Soon the set user ID (set-UID) mechanism was added. These, followed by groups, set group ID (set-GID), and the chroot mechanism have historically been the cornerstones of Unix security.

root

Each UNIX user is assigned a unique user identification number, or user ID. The system recognizes a particular user ID, that of the super-user, to have no access control restrictions. Conventionally, the user name of the super-user is root, and the ID is 0. Note that any user with an ID of 0 would be the super-user. On a typical Unix system, root can do "everything" — an all-or-nothing approach. Consequently traditional Unix security largely boils down to securing the root account.

An early UNIX manual page (circa 1971) for su reads like the following:

NAME su -- become privileged user SYNOPSIS su password DESCRIPTION su allows one to become the super-user, who has all sorts of marvelous powers. In order for su to do its magic, the user must pass as an argu- ment a password. If the password is correct, su will execute the shell with the UID set to that of the super-user. To restore normal UID privileges, type an end-of-file to the super-user shell.

Access Control

The first edition (1971) only had the following file modes (octal) in the i-node:

01 write for non-owner 02 read for non-owner 04 write for owner 10 read for owner 20 executable 40 set-UID

Additionally, traditional Unix systems have provided discretionary access control: it is at the discretion of the owner of an object to designate who all can access it. For example, Unix file permission bits allow a file owner to specify who all have what type of access to a file. This notion of "who all" is coarse-grained, consisting of the file owner, users in the same group as the file owner, and everybody else. Access types include read, write, and execute. As we shall see in a later section, newer systems, including several Unix systems, provide flexible and more powerful access control mechanisms.

Early UNIX versions did not have the concept of groups. Moreover, there was only one executable bit, for both the owner and non-owners. Access control was refined over time to be more flexible and powerful.

Another bit added later was the sticky bit. It served as an optimization flag for executable files (now obsolete), and plays a role in directory permissions. If the sticky bit is set on a writable directory, a non-root user cannot delete or rename a file belonging to another user (unless the file resides in a directory owned by the user trying to delete it). A typical use of the sticky bit is in shared writable directories, such as /tmp:

% ls -lsdL /tmp 0 drwxrwxrwt 21 root wheel 714 26 Jan 00:00 /tmp

Set-UID

Dennis Ritchie filed for a patent on the set-UID mechanism (Protection of Data File Contents) on July 9, 1973. The patent was granted on January 16, 1979 (U.S. Patent 4,135,240). The abstract of the patent is reproduced below:

"An improved arrangement for controlling access to data files by computer users. Access permission bits are used in the prior art to separately indicate permissions for the file owner and nonowners to read, write and execute the file contents. An additional access control bit is added to each executable file. When this bit is set to one, the identification of the current user is changed to that of the owner of the executable file. The program in the executable file then has access to all data files owned by the same owner. This change is temporary, the proper identification being restored when the program is terminated."

Interestingly, Ritchie's set-UID patent application was initially rejected, as the patent examiner considered the disclosure lacking in details. In the examiner's opinion, an ordinary programmer could not implement the mechanism by reading Ritchie's description. Ritchie took care of this issue by writing a small toy operating system with the UNIX file protection mechanism (without the set-UID portion), and gave it to a programmer in the local computer center, who implemented set-UID based on Ritchie's description, and signed an affidavit to that effect.

The fundamental problem solved by set-UID is that it allows a program running on behalf of one user operate as if it were running as another user. Consider an example. Suppose there is a sensitive file on a multi-user system that contains information about each user (/etc/passwd, say), and it is desirable to allow each user to edit his own information in the file (the password, or the so-called GECOS field, say). The typical Unix solution is to have the password setting utility (passwd) be set-UID root. The passwd program is runnable by anybody, but it runs as root, and therefore is able to edit the password file. Since the program exposes very specific and limited legitimate functionality, things are fine as long as it is not possible to make the program do something unintended.

Early examples of set-UID use included a game-playing program that maintained records of players' scores (and thus required write-access to the scores file on behalf of a player).

The set-UID (and set-GID) mechanism went on to become an integral part of Unix, but also has been a primary vehicle for attacks against security, largely due to its all-or-nothing nature.

Today, a Unix process might have a number of user-id's (uid's), and correspondingly, a number of group-id's (gid's):

Others

The chroot mechanism changes the root directory of the calling process to a new directory. Thus, the starting point for path searches of pathnames beginning with '/' is altered. Only the super-user may use this mechanism.

Most Unix systems allow filesystems to be mounted with limited file permissions, or otherwise restricted semantics. For example, a filesystem may be mounted read-only, with device files disallowed, with no executability (so that users cannot execute programs residing in the filesystem), remapped user and group IDs, etc.

Today's mainstream Unix systems include numerous more powerful mechanisms than the common-denominator variety listed here. We look at some in the next sections.

Note that having the mechanisms is one thing, but using them effectively is another. Expert system administration is still one of the most important ingredients of good system security.

<<< Popular Notions About Security main Security Uprooting Vehicles >>>