IDs associated with a process can change during the course of program execution. The importance of this capability in UNIX and similar security models cannot be overemphasized. The ability to increase your security privileges by changing your EUID, EGID, RUID, or RGID is one of the basic notions in the UNIX security model. This privilege escalation mechanism is at the root (pun intended) of many UNIX hacks. The chief goal of most hacking attempts is to gain root privileges to exercise total control over the system. If you do not know or cannot guess the root password, the quickest path to becoming root is to log in as another user and find a way to change one of the UIDs to zero—the UID of the root user. Related hacks involve changing one of the IDs to any user or group on the system other than the current user. Even incrementally increasing your privileges to those of nonroot users might lead to eventually compromising the root account.

You can change who a UNIX system thinks you are in two ways:

•  You can explicitly change the IDs associated with a process by invoking library or kernel routines.

•  You also can let the system automatically change your identity based on access permissions that are set for program files on the system.

This latter technique is the one you will explore first as you investigate access control rules for UNIX files and directories.

UNIX File and Directory Permissions

The UNIX operating system provides a hierarchical virtual file system that might consist of multiple physical storage devices. Each entry in the file system represents a file or directory. The file abstraction is used in the normal sense as a container for data, but in UNIX, the file abstraction also encompasses other concepts such as sockets, character and block devices, and even system memory. Many major UNIX entities are implemented in the file system in one way or another.

The basic storage identifier is an inode that contains information about a file-system object. Each inode is associated with an owner UID and GID. These values are assigned when the file is created but can be changed later using the chown or chgrp command or with a corresponding library routine if invoked from a program. An inode can have only a single owner and a single group ID associated with it.

Traditional UNIX systems support DAC through the use of permission bits. Stored with each inode is a 16-bit mode word that controls access to the files represented by the inode. The least significant nine bits are the most important. Access control in UNIX can be specified for either the file’s owner, the file’s group, or all others. The three primary access modes are read (R), write (W), and execute (X). The interpretation for these modes varies for files and directories as shown in Table 3.1.

Notice that these interpretations lead to some interesting conditions. If you have execute permission for a directory but not read permission, you can run programs but only if you know the name of the program. You cannot search the directory or list its contents to find the name of the program. In addition, if the file or program you want to access is nested deep within several subdirectories, you must have execute permissions to traverse the directory path.

The ls command displays the permission bit settings for a file or directory. Additional arguments for ls cause it to reveal other inode attributes including file create date, last access time, and last change of any value in the inode (such as the file’s length). See Figure 3.1 for an example of a directory listing.

Figure 3.1  Sample UNIX directory listing.

In this example, the file entry for the file gunzip divulges important security information, such as the following:

•  The user who owns the file, the one whose name is “bin.”

•  The group owner of the file is also group “bin” (although it could have been a different group).

•  The file is composed of 110 512K blocks.

•  The last modification time of the file was Mar 09 at 17:28.

•  The file’s inode has a link count of 1, meaning that no other files on the system reference this inode (such as through a hard link).

•  The permissions are read, write, and execute for the owner; read and write for anyone in group bin; and only execute for any other user.

Another value that can be set in the inode’s 16-bit mode field is the sticky bit. The original design of UNIX required that some directories be writeable by all users on the system. In general, this feature is not desirable in a software product. Nonetheless, the /tmp directory has always been writeable by anyone. To prevent users from deleting files that they do not own, the directory’s sticky bit can be set. A command for setting the typical permissions for the /tmp directory would be as follows:

chmod 7777 /tmp

The first 7 sets the sticky bit and the remaining 7s respectively enabled read, write, and execute permissions for owner, group, and world (or user, group, and other). World-writeable directories are not recommended. If you must use them, at least set the sticky bit to prevent the malicious deleting of files.

Other mode bits that can be set include the set user ID and set group ID bits, SUID and SGID respectively. When a file’s SUID bit is enabled, program execution can result in increased privileges for the requesting user. Recall that as a normal user on the system, you do not have sufficient privileges to perform all tasks on a system. For example, normal users are not allowed to write a new password directly into the shadow password file. Instead, to change your password, you must execute a privileged program that changes the password on your behalf. Hopefully, the program is well behaved. If not, the flaw can be exploited by you or any interested hacker.