Securing Users and Processes in Oracle® Solaris 11.2

Exit Print View

Updated: July 2014
 
 

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 image. 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

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(5) man page.