Go to main content

Securing Users and Processes in Oracle® Solaris 11.4

Exit Print View

Updated: November 2020

Process Rights Management

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.

Privileges Protecting Kernel Processes

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.

Privilege Descriptions

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:

        Allows a process to assign a new task ID to the calling process.

The definition of the net_rawaccess privilege indicates its broad effect:

        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.

Administrative Differences on a System With 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.

Table 2  Visible Differences Between a System With Privileges and a System Without Privileges
No Privileges
Daemons run as root.
Daemons run as the user daemon.
For example, these daemons are assigned limited privileges and run as daemon: lockd and rpcbind.
Log file ownership
Log files are owned by root.
Log files are owned by daemon, who creates the log file. The root user does not own the file.
Error messages
Error messages refer to superuser.
For example, chroot: not superuser.
Error messages reflect the use of privileges.
For example, the equivalent error message for chroot failure is chroot: exec failed.
setuid programs
Programs use setuid root to complete tasks that regular users are not allowed to perform.
Many setuid root programs run with just the privileges they need.
For example, the following commands use privileges: audit, ikeadm, ipadm, ipsecconf, ping, traceroute, and newtask.
File permissions
Device permissions are controlled by DAC. For example, members of the group sys can open /dev/ip.
File permissions (DAC) do not predict who can open a device. Devices are protected with DAC and device policy.
For example, the /dev/ip file has 666 permissions, but the device can only be opened by a process with the appropriate privileges.
Audit events
Auditing the use of the su command covers many administrative functions.
Auditing the use of privileges covers most administrative functions. The cusa audit class includes audit events that monitor administrative functions.
Processes are protected by the rights of the process owner.
Processes are protected by privileges. Process privileges and process flags are visible as a new entry in the /proc/<pid>/priv directory.
No reference to privileges in core dumps.
The ELF note section of core dumps includes information about process privileges and flags in the NT_PRPRIV and NT_PRPRIVINFO notes.
The ppriv command and other commands show the proper number of properly sized sets. The commands correctly map the bits in the bit sets to privilege names.