| Previous | Table of Contents | Next |
The /etc/passwd file can be read by any user on the system. Because password information is stored in this file, someone may be able to guess or crack passwords. For increased security, most modern UNIX variants rely on a shadow password file that is stored in a directory which only certain users can read—notably root and perhaps a security administrator. The system then would rely on both /etc/passwd and another file, such as /etc/security/passwd in IBM’s AIX version of UNIX. In this shadow configuration, passwords are stored in the shadow password file and the other user information from Table 2.1 remains in /etc/passwd. Technically, user information for AIX is stored in /etc/passwd, /etc/security/user, and /etc/security/passwd. UNIX operating systems may depend on many different files for user and group data, but /etc/passwd is always present.
Most UNIX systems ship with a default set of usernames and UIDs. These accounts have special privileges throughout the system. Of particular interest is UID zero (0) which identifies the superuser. On most UNIX operating systems, this UID is associated with the username root. With the exception of a few operations, the root user is given complete control over the machine and operating system.
The preceding comments assume that the version of UNIX you are using has not been modified in a special way that prevents root from controlling the entire system. Some UNIX variants implement a security model based on privileges that can be used to more tightly constrain the root user’s actions. UNIX derivatives that have the majority of the market share implement only discretionary access control (DAC) at best, and as a result, suffer from the root problem. If a person can gain root access to a system, that person then can do almost anything on the system. This problem will be analyzed in more detail when you learn about access control in Chapter 3, “The Role of Access Control in Your Environment.”
Although users and groups are important entities in the UNIX security model, the main subject in the model is the process. A process is a program running within the context of the operating system. Every process is associated with a UID and one or more GIDs. Technically, several UIDs and GIDs for each process are available, but it is better to momentarily consider a simpler model in which a process is associated with a single UID and with one or more GIDs. Each process also is assigned an integer process ID or PID to uniquely differentiate it from other processes. When the login phase is complete for a user, the operating system constructs a process to execute on behalf of that user. This user process is tagged with the UID and GIDs assigned to that user in /etc/passwd and /etc/group.
If the I&A step succeeds, the operating system will know both your UID and GIDs. To create a process, the operating system initializes several data structures in the kernel and starts a program for the user who is requesting access. The program started after I&A is the shell defined for the user in /etc/passwd. From the shell a user can start other programs or exit the system. Notice that the operating system assigns the initial UID and GIDs, or the credentials, for the shell process.
The operating system also provides interfaces for changing the UID and primary GID of a process. Because the UID and GIDs are used in access control decisions made by the operating system, changing your UID or GID can give you additional (or fewer) privileges on the system. As such, the mechanisms for changing credentials in an operating system must be tightly controlled. Numerous attacks have been made on systems as a result of implementation problems in this area. Briefly, here is what happens.
By design, a program with special privileges can be executed by arbitrary users. The program needs special privileges because it must access some portion of the file system or a device that a normal user cannot. Due to a bug in its implementation, the privileged program can be diverted into doing something that it was not supposed to do. In many cases, the program is tricked into giving the normal user enough power to become the root user on the system. If such a flaw exists and if local users can take advantage of that flaw, you have a serious security problem. If a remote user can exploit this weakness without a login account on your system, such as by supplying data to a form on your Web server, you have a catastrophic problem!
UNIX processes are related hierarchically. As part of the initial boot sequence, the UNIX kernel starts the init process, which is the parent of all other processes on the system. To enable logins into the system, init will start a getty program for each terminal (TTY) attached to the system. The getty program performs several tasks unrelated to I&A (setting terminal line speed, for example) and then displays a login prompt. Both init and getty run with root privileges. In other words, they have a UID of 0.
When a person finishes typing in a username at the terminal login prompt and then presses the Enter or Return key, getty will overlay itself with the login program and pass to it the username just captured. The login program inherits root privileges because it is started as a child of getty. One of the defining characteristics of UNIX is this notion of process inheritance. When a parent process starts a child process, as a default behavior in UNIX, the child inherits many of the data structures being used by the parent, including the parent’s security credentials.
Login next prompts the user to enter a password. Any keystrokes made by the user are not echoed to the screen to prevent shoulder surfing—an old hacker attack. If the password entered is correct, the login program then adds the following:
| Previous | Table of Contents | Next |