|Skip Navigation Links|
|Exit Print View|
|Transitioning From Oracle Solaris 10 to Oracle Solaris 11 Oracle Solaris 11 Information Library|
The following information describes how roles, rights and privileges work in 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. In Oracle Solaris 11, two new suffixes, .assign and .delegate, for example, solaris.profile.assign and solaris.profile.delegate, are used. 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.
Media Restore rights profile – This rights profile and 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:
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. See user_attr(4).
root as a Role – root is now a role by default, 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 Oracle Solaris Administration: Security Services.
Oracle Solaris 11 basic privileges include the following:
Profile shell versions of regular shells – Every regular shell now has its own profile version. The following profile shells are available:
Rights profiles – The user_attr, prof_attr, and exec_attr databases are now read-only. These local files databases are assembled from fragments that are located in /etc/user_attr.d, /etc/security/prof_attr.d, and /etc/security/exec_attr.d. The fragment files are not merged into a single version of the file, but left as fragments. This change enables packages to deliver complete or partial RBAC profiles. Entries that are added to the local files repository with the useradd and profiles commands are added to the local-entries file in the fragment directory. To add or modify a profile, use the profiles command. See How to Create or Change a Rights Profile in Oracle Solaris Administration: Security Services.
Stop rights profile – This profile enables administrators to create restricted accounts. See RBAC Rights Profiles in Oracle Solaris Administration: Security Services.
pfsh script command – This command now runs the same as the pfsh -c script command. Previously, commands within a script would not be able to take advantage of RBAC, unless the script specified a profile shell as its first line. This rule required you to modify any scripts to use RBAC, which is now unnecessary because the caller of the script (or an ancestor within the session) can specify a profile shell.
pfexec command – This command is now 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.
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 now searches for an entry in the Forced Privilege RBAC 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 RBAC execution profile have assigned to that path name.
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). The privilege format that is displayed is used by developers.
$ man privileges Standards, Environments, and Macros privileges(5) NAME privileges - process privilege model ... The defined privileges are: PRIV_CONTRACT_EVENT 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. ...
Example 9-1 Viewing Directly-Assigned Privileges
If you have been directly assigned privileges, then your basic set contains more than the default basic set. In the following example, the user always has access to the proc_clock_highres privilege.
$ /usr/bin/whoami jdoe $ ppriv -v $$ 1800: pfksh flags = <none> E: file_link_any,…,proc_clock_highres,proc_session I: file_link_any,…,proc_clock_highres,proc_session P: file_link_any,…,proc_clock_highres,proc_session L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time $ ppriv -vl proc_clock_highres Allows a process to use high resolution timers.