This section covers privilege implementation, use, and assignment details.
Every process has four sets of privileges that determine whether a process can use a particular privilege. The kernel automatically calculates the effective set of privileges. You can modify the initial inheritable set of privileges. A program that is coded to use privileges can reduce the program's permitted set of privileges. You can shrink the limit set of privileges.
Effective privilege set, or E – The set of privileges that is currently in effect. A process can add privileges that are in the permitted set to the effective set. A process can also remove privileges from E.
Permitted privilege set, or P – The set of privileges that is available for use. Privileges can be available to a program from inheritance or through assignment. An execution profile is one way to assign privileges to a program. The setuid command assigns all privileges that root has to a program. Privileges can be removed from the permitted set but not added. Privileges that are removed from P are automatically removed from E.
A privilege-aware program removes the privileges that a program never uses from the program's permitted set. In this way, unnecessary privileges cannot be exploited by the program or a malicious process. For more information about privilege-aware programs, see Chapter 2, Developing Privileged Applications in Developer’s Guide to Oracle Solaris 11.4 Security.
Inheritable privilege set, or I – The set of privileges that a process can inherit across a call to exec. After the call to exec, the inherited privileges are placed in the permitted set and the effective set, thus making these sets equal, except in the special case of a setuid program.
For a setuid program, after the call to exec, the inheritable set is first restricted by the limit set. Then, the set of privileges that were inherited (I), minus any privileges that were in the limit set (L), are assigned to P and E for that process.
Limit privilege set, or L – The set that defines the outside limit of which privileges are available to a process and its children. By default, the limit set is all privileges. Processes can shrink the limit set but can never extend the limit set. L is used to restrict I. Consequently, L restricts P and E at the time of exec.
If a user has been assigned a profile that includes a program that has been assigned privileges, the user can usually run that program. On an unmodified system, the program's assigned privileges are within the user's limit set. The privileges that have been assigned to the program become part of the user's permitted set. To run the program that has been assigned privileges, the user must run the program from a profile shell.
The kernel recognizes a basic privilege set. On an unmodified system, each user's initial inheritable set equals the basic set at login. While you cannot modify the basic set, you can modify which privileges a user inherits from the basic set.
On an unmodified system, a user's privilege sets at login would appear similar to the following:
E (Effective): basic I (Inheritable): basic P (Permitted): basic L (Limit): all
At login, all users would have the basic set in their inheritable set, their permitted set, and their effective set. A user's limit set is equivalent to the default limit set for the zone, global or non-global.
You can assign additional privileges directly to a user, or more precisely to a user's login process, indirectly to many users through a rights profile, and indirectly by assigning a privileged command to a user. You can also remove privileges from a user's basic set. For procedures and examples, see Assigning Rights in Oracle Solaris.
Privileges are built into Oracle Solaris. This section describes how Oracle Solaris uses privileges with devices, in resource management, and with legacy applications.
Processes can inherit privileges or be assigned privileges. A process inherits privileges from its parent process. At login, the user's initial inheritable set of privileges determines which privileges are available to the user's processes. All child processes of the user's initial login inherit that set.
You can also directly assign privileges to programs, users, roles, and specific resources. When a program requires privileges, you assign the privileges to the program's executable in a rights profile. Users or roles that are permitted to run the program are assigned the profile that includes the program. At login or when a profile shell is opened, the program runs with privilege when the program's executable is typed in the profile shell. For example, a role that includes the Object Access Management profile is able to run the chmod command with the file_chown privilege, and therefore can change the ownership of a file that the role does not own.
When a role or user runs a program that has been directly assigned an additional privilege, the assigned privilege is added to the role or user's inheritable set. Child processes of the program that was assigned privileges inherit the privileges of the parent. If the child process requires more privileges than the parent process, the child process must be directly assigned those privileges.
Programs that are coded to use privileges are called privilege-aware programs. A privilege-aware program enables and disables the use of privilege during program execution. To succeed in a production environment, the program must be assigned the privileges that the program enables and disables. Before you make a privilege-aware program available, you assign to the executable only the privileges that the program needs. You then test the program to see that the program succeeds in performing its tasks. You also check that the program does not abuse its use of privileges.
For examples of privilege-aware code, see Chapter 2, Developing Privileged Applications in Developer’s Guide to Oracle Solaris 11.4 Security. To assign privileges to a program that requires privileges, see Example 38, Assigning Security Attributes to a Legacy Application and Example 49, Creating a Rights Profile That Includes Privileged Commands.
In the rights model, privileges protect system interfaces that in the superuser model are protected by file permissions alone. In a system with privileges, file permissions are too weak to protect the interfaces. A privilege such as proc_owner could override file permissions and then gain full access to the system.
Therefore, in Oracle Solaris, ownership of the device directory is not sufficient to open a device. For example, members of the group sys are no longer automatically allowed to open the /dev/ip device. The file permissions on /dev/ip are 0666, but the net_rawaccess privilege is also required to open the device.
Because device policy is controlled by privileges, you have more flexibility in granting permission to open devices. Privilege requirements are configurable for the device policy and for the driver proper. You can configure the privilege requirements when installing, adding, or updating a device driver.
For more information, see the add_drv(8), devfsadm(8), getdevpolicy(8), and update_drv(8) man pages.
In Oracle Solaris, you can use the project.max-locked-memory and zone.max-locked-memory resource controls to limit the memory consumption of processes that are assigned the PRIV_PROC_LOCK_MEMORY privilege. This privilege allows a process to lock pages in physical memory.
If you assign the PRIV_PROC_LOCK_MEMORY privilege to a rights profile, you can give the processes that have this privilege the ability to lock all memory. As a safeguard, set a resource control to prevent the user of the privilege from locking all memory. For privileged processes that run in a non-global zone, set the zone.max-locked-memory resource control. For privileged processes that run on a system, create a project and set the project.max-locked-memory resource control. For information about these resource controls, see Chapter 6, About Resource Controls in Administering Resource Management in Oracle Solaris 11.4 and Chapter 1, Non-Global Zone Configuration Command and Resources in Oracle Solaris Zones Configuration Resources.
To accommodate legacy applications, the implementation of privileges works with both the superuser and the rights models. The kernel automatically tracks the PRIV_AWARE flag, which indicates that a program has been designed to work with privileges. Consider a child process that is not aware of privileges. Any privileges that were inherited from the parent process are available in the child's permitted and effective sets. If the child process sets a UID to 0, the child process might not have full superuser rights. The process's effective and permitted sets are restricted to those privileges in the child's limit set. Thus, the limit set of a privilege-aware process restricts the root privileges of child processes that are not aware of privileges.
Oracle Solaris provides tools to debug privilege failure. The ppriv command and the truss command provide debugging output. For examples, see the ppriv(1) man page. For examples, see Troubleshooting RBAC and Privileges. You can also use the dtrace command. For more information, see the dtrace(8) man page and Oracle Solaris 11.4 DTrace (Dynamic Tracing) Guide.
The term "privilege" traditionally indicates an increase in rights. Because every process on an Oracle Solaris system runs with some rights, you can decrease the rights on a process by removing privileges. In this release, you can also use an extended privilege policy to remove most privileges except the ones that are given to certain resources by default.
In your capacity as security administrator, you are responsible for assigning privileges. Existing rights profiles have privileges already assigned to commands in the profile. You then assign the rights profile to a role or user.
Privileges can also be assigned directly to a user, a role, or a rights profile. If you trust a subset of users to use a privilege responsibly throughout their sessions, you can assign the privilege directly. Good candidates for direct assignment are privileges that have a limited effect, such as proc_clock_highres. Poor candidates for direct assignment are privileges that have broader effects, such as file_dac_write. For a fuller discussion, see Security Considerations When Assigning Rights.
Privileges can also be denied to a user, role, or process. Care must be taken when removing privileges from the initial inheritable set or the limit set of a user or role.
Users and roles have an inheritable set of privileges. The limit set can only be reduced because the limit set is initially all privileges. The initial inheritable set can be expanded for users, roles, and processes by assigning a privilege that is not in the inheritable set.
You can expand the privileges that are available in three ways:
A privilege that is not in the initial inheritable set but is in the limit set can be assigned to users and roles. The assignment can be indirect, through a privileged command in a rights profile, or it can be direct.
A privilege that is not in the inheritable set can be explicitly assigned to a process, such as adding privileges to a script or application.
A privilege that is not in the inheritable set but is in the limit set can be explicitly assigned to a network port, UID, or file object. This use of privilege is called an extended privilege policy and is also a means of restricting available privileges. For more information, see Using Extended Privilege Policy to Restrict Privilege Use.
The assignment of a privilege to just the administrative task that requires the privilege is the most precise way to expand a user or role's privileges. You create a rights profile that includes the command or script with its required privileges. Then, you assign this rights profile to a user or role. Such assignment enables the user or role to run that privileged command. The privilege is otherwise unavailable to the user.
Expanding the initial inheritable set of privileges for users or roles is a less desirable way to assign privileges. All privileges in the inheritable set are in the permitted and effective sets. All commands that the user or role types in a shell can use the directly assigned privileges. For a fuller discussion, see Security Considerations When Assigning Rights.
To reduce unnecessary privilege availability, you can assign extended privileges to network ports, UIDs, and file objects. Such assignment removes privileges that are not in the extended privilege assignment from the effective set. For a discussion, see Using Extended Privilege Policy to Restrict Privilege Use.
Privileges and rights profiles can also be applied to untrusted users to restrict their rights. By removing privileges, you can prevent users and roles from performing particular tasks. You can remove privileges from the initial inheritable set and from the limit set. You should carefully test removal of privileges before you distribute an initial inheritable set or a limit set that is smaller than the default set. By removing privileges from the initial inheritable set, you might prevent users from logging in. When privileges are removed from the limit set, a legacy setuid root program might fail because the program requires a privilege that was removed. For examples of privilege removal, see Removing Privileges From Users.
To limit the privileges that are available to a user ID, port, or file object, see Using Extended Privilege Policy to Restrict Privilege Use.
Scripts are executables, like commands. Therefore, in a rights profile, you can add privileges to a script just as you can add privileges to a command. The script runs with the added privileges when a user or role who has been assigned the rights profile executes the script in a profile shell. If the script contains commands that require privileges, the commands with added privileges must also be in an assigned rights profile. For examples, see Assigning Rights to Applications and Scripts.
Extended privilege policy can restrict access to ports, user IDs, or file objects except for the basic privileges and the privileges that you explicitly grant. With so few privileges, the resource cannot easily be used to attack the system. In fact, users can protect files and directories that they own from access by potentially malicious processes. For examples of extended privilege policy, see Limiting Applications, Scripts, and Resources to Specific Rights.
Oracle Solaris provides administrators with a great deal of flexibility when configuring security. As installed, the software prevents privilege escalation. Privilege escalation occurs when a user or process gains more administrative rights than you intended to grant. In this sense, "privilege" means all rights, not just kernel privileges. See Privilege Escalation and Kernel Privileges.
Oracle Solaris software includes rights that are assigned to the root role only. With other security protections in place, an administrator might assign attributes that are designed for the root role to other accounts, but such assignment must be made with care.
The following rights profile and set of authorizations can escalate the privileges of a non-root account:
Media Restore rights profile – This profile is not part of any other rights profile. Because Media Restore provides access to the entire root file system, its use is a possible escalation of privilege. Deliberately altered files or substitute media could be restored. By default, the root role includes this rights profile.
solaris.*.assign authorizations – These authorizations are not assigned to any rights profile. An account with a solaris.*.assign authorization could assign rights to others that the account itself is not assigned. For example, a role with the solaris.profile.assign authorization can assign rights profiles to other accounts that the role itself is not assigned. By default, only the root role has solaris.*.assign authorizations.
Assign solaris.*.delegate authorizations, rather than solaris.*.assign authorizations. A solaris.*.delegate authorization enables the delegater to assign other accounts only those rights that the delegater possesses. For example, a role that is assigned the solaris.profile.delegate authorization can assign rights profiles that the role itself is assigned to other users and roles.
For the prevention of escalation of kernel privileges, see Privilege Escalation and Kernel Privileges.
The kernel prevents privilege escalation. To prevent a process from gaining more privileges than the process should have, the kernel checks that vulnerable system modifications have the full set of privileges. For example, a file or process that is owned by root (UID=0) can be changed only by a process with the full set of privileges. The root account does not require privileges to change a file that root owns. However, a non-root user must have all privileges in order to change a file that is owned by root.
Similarly, operations that provide access to devices require all privileges in the effective set.
Specifically, the file_chown_self and proc_owner privileges are subject to privilege escalation.
The file_chown_self privilege allows a process to give away its files. The proc_owner privilege allows a process to inspect processes that the process does not own.
The file_chown_self privilege is limited by the rstchown system variable. When the rstchown variable is set to 0, the file_chown_self privilege is removed from the initial inheritable set of all users of the system. For more information about the rstchown system variable, see the chown(1) man page.
The file_chown_self privilege is most safely assigned to a particular command, the command placed in a rights profile, and the profile assigned to a role or a trusted user.
The proc_owner privilege is not sufficient to switch a process UID to 0. To switch a process from any UID to UID=0 requires all privileges. Because the proc_owner privilege gives unrestricted read access to all files on the system, the privilege is most safely assigned to a particular command, the command placed in a profile, and the profile assigned to a role.
Caution - You can configure a user's account to include the file_chown_self privilege or the proc_owner privilege in the user's initial inheritable set. However, you should have overriding security reasons for placing such powerful privileges in any user or role's inheritable set. |
For information about how privilege escalation is prevented for devices, see Privileges and Devices. For a general discussion, see the privileges(7) man page.