Process rights management in Oracle Solaris is implemented by privileges. Privileges enable processes to be restricted at the level of command, user, role, and specific system resource. Privileges decrease the security risk that is associated with one user or one process having full superuser powers on a system. Process rights and user rights provide a compelling alternative model to the traditional superuser model.
Traditionally, privileges are used to add rights. However, privileges can also be used to restrict rights, for example, changing a setuid root program to a program that is privilege-aware. Also, with an extended privilege policy, administrators can allow only specified privileges to be used with a file object, user ID, or port. This fine-grained privilege assignment denies all other privileges except basic privileges to these resources.
For information about extended privilege policy and restrictive privileges, see Using Extended Privilege Policy to Restrict Privilege Use.
For information about user rights, see User Rights Management.
For information about how to administer privileges, see Assigning Rights in Oracle Solaris.
For reference information about privileges, see Privileges Reference.
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. Figure 1, Table 1, Superuser Model Contrasted With Rights Model 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.
Privileges are logically grouped on the basis of the area of the privilege.
FILE privileges – Privileges that begin with the string file operate on file system objects. For example, the file_dac_write privilege overrides discretionary access control when writing to files.
IPC privileges – Privileges that begin with the string ipc override IPC object access controls. For example, the ipc_dac_read privilege enables a process to read remote shared memory that is protected by DAC.
NET privileges – Privileges that begin with the string net give access to specific network functionality. For example, the net_rawaccess privilege enables a device to connect to the network.
PROC privileges – Privileges that begin with the string proc allow processes to modify restricted properties of the process itself. PROC privileges include privileges that have a very limited effect. For example, the proc_clock_highres privilege enables a process to use high resolution timers.
SYS privileges – Privileges that begin with the string sys give processes unrestricted access to various system properties. For example, the sys_linkdir privilege enables a process to make and break hard links to directories.
Other logical groups include CONTRACT, CPC, DAX, DTRACE, GRAPHICS, VIRT, and WIN.
Some privileges have a limited effect on the system, and some have a broad effect. The definition of the proc_taskid privilege indicates its limited effect:
proc_taskid
Allows a process to assign a new task ID to the calling process.
The definition of the net_rawaccess privilege indicates its broad effect:
net_rawaccess
Allows a process to have direct access to the network layer.
The privileges(7) man page provides descriptions of every privilege. See also Listing Privileges.
A system that has privileges has several visible differences from a system that does not have privileges. The following table lists some of the differences.
|