A privilege is a right that a process requires to perform an operation. The right is enforced in the kernel. A program that operates within the bounds of the basic set of privileges operates within the bounds of the system security policy. setuid root programs are examples of programs that operate outside the bounds of the system security policy. By using privileges, programs eliminate the need for calls to setuid root.
Privileges enumerate the kinds of operations that are possible on a system. Programs can be run with the exact privileges that enable the program to succeed. For example, a program that manipulates files might require the file_dac_write and file_flag_set privileges. These privileges on the process eliminate the need to run the program as root.
Historically, systems have not followed the privilege model, or rights model, as introduced in Basics of User and Process Rights. Rather, systems used the superuser model. In the superuser model, processes were run as root or as a user. User processes were limited to acting on the user's directories and files. root processes could create directories and files anywhere on the system. A process that required creation of a directory outside the user's directory would run with a UID=0, that is, as root. Security policy relied on discretionary access control (DAC) to protect system files. Device nodes were protected by DAC. For example, devices owned by the group sys could be opened only by members of that group.
However, setuid programs, file permissions, and administrative accounts are vulnerable to misuse. The actions that a setuid process is permitted are more numerous than the process requires to complete its operation. A setuid root program can be compromised by an intruder who then runs as the all-powerful root user. Similarly, any user with access to the root password can compromise the entire system.
In contrast, a system that enforces policy with privileges provides a gradation between user rights and root rights. A user can be granted privileges to perform activities that are beyond the rights of regular users, and root can be limited to fewer privileges than root currently possesses. With rights, a command that runs with privileges can be isolated in a rights profile and assigned to one user or role. Table 1–1 summarizes the gradation between user rights and root privileges that the rights model provides.
The rights model provides greater security than the superuser model. Privileges that have been removed from a process cannot be exploited. Process privileges can provide an additional safeguard for sensitive files and devices in contrast to DAC protections alone, which can be exploited to gain access.
Privileges, then, can restrict programs and processes to just the rights that the program requires. On a system that implements least privilege, an intruder who captures a process can access only those privileges that the process has. The rest of the system cannot be compromised.