The following is a list of the reference information in this chapter:Administrative Commands for Handling Privileges Files With Privilege Information Privileges and Auditing Prevention of Privilege Escalation Legacy Applications and the Privilege Model To use privileges, see Chapter 11, Privileges (Tasks). For overview information, see Privileges (Overview). privilegescommandscommandsfor administering privilegesThe following table lists the commands that are available to handle privileges.Purpose Command Man Page Examine process privileges ppriv -v pid ppriv1 Set process privileges ppriv -s spec List the privileges on the system ppriv -l List a privilege and its description ppriv -lv priv Debug privilege failure ppriv -eD failed-operation Assign privileges to a new local user useradd useradd1M Add privileges to an existing local user usermod usermod1M Assign privileges to a user in a name service smuser smuser1M Assign privileges to a new local role roleadd roleadd1M Add privileges to an existing local role rolemod rolemod1M Assign privileges to a role in a name service smrole smrole1M View device policy getdevpolicy getdevpolicy1M Set device policy devfsadm devfsadm1M Update device policy on open devices update_drv -p policy driver update_drv1M Add device policy to a device add_drv -p policy driver add_drv1M The Solaris Management Console GUI is the preferred tool for assigning privileges to commands, users, and roles. For more information, see How to Assume a Role in the Solaris Management Console. privilegesfiles databaseswith privilege information fileswith privilege information configuration fileswith privilege information defaultsprivilege settings in policy.conf filepolicy.conf filekeywordsfor privilegesThe following files contain information about privileges.File and Man Page Keyword Description /etc/security/policy.confpolicy.conf4 PRIV_DEFAULT keywordpolicy.conf filePRIV_DEFAULT Inheritable set of privileges for the system PRIV_LIMIT keywordpolicy.conf filePRIV_LIMIT Limit set of privileges for the system /etc/user_attruser_attr4 defaultpriv keyword user_attr databaseuser_attr databasedefaultpriv keyworddefaultpriv keyword in user or role's entryValue is usually set in the Solaris Management Console GUI Inheritable set of privileges for a user or role limitpriv keyworduser_attr databaseuser_attr databaselimitpriv keywordlimitpriv keyword in user or role's entryValue is usually set in the Solaris Management Console GUI Limit set of privileges for a user or role /etc/security/exec_attrexec_attr4 privs keyword in the profile's entry for the commandPolicy for the command must be solaris List of privileges that are assigned to a command in a rights profile syslog.confsyslog.conf4 System log file for debug messagesconfiguration filessyslog.conf filepriv.debug entrysyslog.conf filesyslog.conf filepriv.debug entryPath set in priv.debug entry Privilege debugging log Do not edit the exec_attr and user_attr databases directly. To administer privileges, use the Solaris Management Console, or commands such as smuser. For more information, see the smc1M and the smuser1M man pages. For procedures, see Managing Privileges (Task Map). auditingprivileges and privilegesauditing and Privilege use can be audited. When a process uses a privilege, the use of privilege is recorded in the audit trail. The privileges are recorded in their textual representation. The following audit events record use of privilege:AUE_SETPPRIV audit event – The event generates an audit record when a privilege set is changed. The AUE_SETPPRIV audit event is in the pm class. AUE_MODALLOCPRIV audit event – The audit event generates an audit record when a privilege is added from outside the kernel. The AUE_MODALLOCPRIV audit event is in the ad class. AUE_MODDEVPLCY audit event – The audit event generates an audit record when the device policy is changed. The AUE_MODDEVPLCY audit event is in the ad class. AUE_prof_cmd audit event – The audit event generates an audit record when a command is executed in a profile shell. The AUE_prof_cmd audit event is in the as and ua audit classes. The successful use of privileges that are in the basic set is not audited. The attempt to use a basic privilege that has been removed from a user's basic set is audited. privilegesescalationThe Solaris kernel prevents privilege escalation. Privilege escalation is when a privilege enables a process to do more than the process should be able to do. To prevent a process from gaining more privileges than the process should have, certain system modifications require the full set of privileges. For example, a file or process that is owned by root (UID=0) can only be changed by a process with the full set of privileges. The root user 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.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 zero, the file_chown_self privilege is removed from the initial inheritable set of the system and of all users. For more information on the rstchown system variable, see the chown1 man page.The file_chown_self privilege is most safely assigned to a particular command, placed in a profile, and assigned to a role for use in a profile shell.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, placed in a profile, and assigned to a role for use in a profile shell.A user's account can be modified to include the file_chown_self privilege or the proc_owner privilege in the user's initial inheritable set. You should have overriding security reasons for placing such powerful privileges in the inheritable set of privileges for any user, role, or system. For details of how privilege escalation is prevented for devices, see Privileges and Devices. To accommodate legacy applications, the implementation of privileges works with both the superuser and the privilege 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 capabilities. 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.