Go to main content

Transitioning From Oracle® Solaris 10 to Oracle Solaris 11.3

Exit Print View

Updated: December 2018

Roles, Rights, Privileges, and Authorizations

    The following information describes how roles, rights, privileges, and authorizations work Oracle Solaris 11:

  • Assign versus delegate authorizations – Oracle Solaris provides authorizations for delegating specific administrative rights to individual users and roles to implement separation of duty. In Oracle Solaris 10, authorizations ending in .grant are required to delegate an authorization to another user. Starting with Oracle Solaris 11, two new suffixes, .assign and .delegate, are used, for example, solaris.profile.assign and solaris.profile.delegate. The former grants the right to delegate any rights profile to any user or role. The latter is more restrictive, in that only the rights profiles that are already assigned to the current user can be delegated. Since the root role is assigned solaris.*, this role can assign any authorization to any user or role. As a safety measure, no authorizations that end in .assign are included in any profiles by default.

  • groupadd command changes – At group creation, the system assigns the solaris.group.assign/groupname authorization to the administrator. This authorization gives the administrator complete control over that group, enabling the administrator to modify or delete the groupname, as needed. See the groupadd(1M) and groupmod(1M) man pages.

  • Media Restore rights profile – This rights profile and its associated set of authorizations can escalate the privileges of a non root account. The profile exists, but is not part of any other rights profile. Because the Media Restore rights profile 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.

  • Primary Administrator profile removed – The initial user that is created at installation time is given the following roles and rights:

    • root role

    • System Administrator rights profile

    • Access to the sudo command for all commands that are run as root

  • Role authentication – You can specify either user or role for the roleauth keyword.

    You can determine which password has been assigned to the root role as follows:

    # userattr roleauth root

    No output means the root account has not been customized, meaning the password is the Oracle Solaris default and not the user's password.

    See user_attr(4).

  • root as a roleroot is a role by default in Oracle Solaris 11, therefore, not anonymous and cannot remotely log in to a system. For information about changing the root role to a user, see How to Change the root Role Into a User in Securing Users and Processes in Oracle Solaris 11.3.

  • To list the basic privileges in your shell, run the ppriv -l basic command.

  • To list the profile shell versions of regular shells, see the pfexec(1) man page.

  • Rights profiles – The user_attr, prof_attr, and exec_attr databases are read-only. To add or modify a rights profile, use the profiles command. See About Rights Profiles.

  • Stop Rights profile – This profile enables administrators to create restricted accounts. See More About Rights Profiles in Securing Users and Processes in Oracle Solaris 11.3.

  • pfsh script command – This command runs the same as the pfsh –c script command. Previously, commands within a script could not take advantage of using rights profiles unless the script specified a profile shell in the first line. This rule required you to modify any scripts to use rights profiles, which is now unnecessary.

  • pfexec command – This command is no longer setuid root. The new PF_PFEXEC process attribute is set when the pfexec command or a profile shell is executed. Then, the kernel sets the appropriate privileges on exec. This implementation ensures that sub-shells are empowered or restricted, as appropriate. Also, the pfexec command prompts the user to re-authenticate if the specified command is included in a rights profile that has been assigned by using the auth_profiles keyword.

    When the kernel is processing an exec (2) , it treats setuid to root differently. Note that setuid to any other uid or setgid is as it was previously. The kernel searches for an entry in the Forced Privilege rights profile in exec_attr (4) to determine which privileges the program should run with. Instead of having the program start with uid root and all privileges, the program runs with the current uid and only the additional privileges that the Forced Privilege execution rights profile have assigned to that path name.

About Rights Profiles

Rights profiles are collections of authorizations and other security attributes, commands with security attributes, and supplementary rights profiles. Oracle Solaris provides many rights profiles. You can modify existing rights profiles, as well as create new ones. Note that rights profiles must be assigned in order, from most to least powerful.

For a list of provided rights profiles, see Chapter 8, Reference for Oracle Solaris Rights in Securing Users and Processes in Oracle Solaris 11.3.

Viewing and Using Privileges and Authorizations

When a user is directly assigned privileges, in effect, the privileges are in every shell. When a user is not directly assigned privileges, then the user must open a profile shell. For example, when commands with assigned privileges are in a rights profile that is in the user's list of rights profiles, then the user must execute the command in a profile shell.

To view privileges online, see privileges(5). Privileges are displayed in the format that developers use. When you are assigned a privilege, it appears as, for example, contract_event, not PRIV_CONTRACT_EVENT.

$ man privileges
Standards, Environments, and Macros                 privileges(5)

privileges - process privilege model
The defined privileges are:


Allow a process to request reliable delivery  of  events
to an event endpoint.

Allow a process to include events in the critical  event
set  term  of  a  template  which  could be generated in
volume by the user.

To view authorizations, use the auths command:

$ auths list

The output of this command produces a more readable summary (one per line) of the authorizations that are assigned to a user. Starting with Oracle Solaris 11.1, several new options have been added to the auths command. See Chapter 8, Reference for Oracle Solaris Rights in Securing Users and Processes in Oracle Solaris 11.3 and the auths(1) man page.