JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris 11.1 Administration: Security Services     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information


Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Verifying File Integrity by Using BART (Tasks)

7.  Controlling Access to Files (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Security Attributes in Oracle Solaris (Reference)

Rights Profiles

Viewing the Contents of Rights Profiles

Order of Search for Assigned Security Attributes


Authorization Naming Conventions

Delegation Authority in Authorizations

RBAC Databases

RBAC Databases and the Naming Services

user_attr Database

auth_attr Database

prof_attr Database

exec_attr Database

policy.conf File

RBAC Commands

Commands That Manage RBAC

Selected Commands That Require Authorizations


Administrative Commands for Handling Privileges

Files With Privilege Information

Privileges and Auditing

Prevention of Privilege Escalation

Legacy Applications and the Privilege Model

Part IV Cryptographic Services

11.  Cryptographic Framework (Overview)

12.  Cryptographic Framework (Tasks)

13.  Key Management Framework

Part V Authentication Services and Secure Communication

14.  Using Pluggable Authentication Modules

15.  Using Secure Shell

16.  Secure Shell (Reference)

17.  Using Simple Authentication and Security Layer

18.  Network Services Authentication (Tasks)

Part VI Kerberos Service

19.  Introduction to the Kerberos Service

20.  Planning for the Kerberos Service

21.  Configuring the Kerberos Service (Tasks)

22.  Kerberos Error Messages and Troubleshooting

23.  Administering Kerberos Principals and Policies (Tasks)

24.  Using Kerberos Applications (Tasks)

25.  The Kerberos Service (Reference)

Part VII Auditing in Oracle Solaris

26.  Auditing (Overview)

27.  Planning for Auditing

28.  Managing Auditing (Tasks)

29.  Auditing (Reference)




Privileges restrict processes are implemented in the kernel, and can restrict processes at the command, user, role, or system level.

Administrative Commands for Handling Privileges

The following table lists the commands that are available to handle privileges.

Table 10-3 Commands for Handling Privilege

Man Page
Examine process privileges
ppriv -v pid
Set process privileges
ppriv -s spec
List the privileges on the system
ppriv -l
List a privilege and its description
ppriv -lv priv
Add extended privilege policy to a UID, process, or port.
ppriv -r rule
Use -X to remove the policy. privileges(5)
List extended privilege policy on a UID, process, or port.
ppriv -lv extended-policy
Debug privilege failure
ppriv -eD failed-operation
Assign privileges to a new user
Add privileges to an existing user
Assign privileges to a rights profile
Assign privileges to a new role
Add privileges to an existing role
View device policy
Set device policy
Update device policy on open devices
update_drv -p policy driver
Add device policy to a device
add_drv -p policy driver

Files With Privilege Information

The following files contain information about privileges.

Table 10-4 Files That Contain Privilege Information

File and Man Page
Privilege Information


Inheritable set of privileges for the system
Limit set of privileges for the system


System log file for debug messages

Path set in priv.debug entry

Privilege debugging log

Privileges and Auditing

Privilege use can be audited. Any time that a process uses a privilege, the use of privilege is recorded in the audit trail in the upriv audit token. When privilege names are part of the record, their textual representation is used. The following audit events record use of privilege:

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.

Prevention of Privilege Escalation

The 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, vulnerable 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 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.

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 about the rstchown system variable, see the chown(1) 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.


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

Legacy Applications and the Privilege Model

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.