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 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 Role – root 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.2 .
Oracle Solaris basic privileges include the following:
file_read
file_write
net_access
Profile shell versions of regular shells – Every regular shell has its own profile version in Oracle Solaris 11. The following profile shells are available:
pfbash
pfcsh
pfksh
pfksh93
pfrksh93
pfsh
pftcsh
pfzsh
See pfexec(1).
Rights profiles – The user_attr, prof_attr, and exec_attr databases are 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 rights 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 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.2 .
pfsh script command – This command runs the same as the pfsh –c script command. Previously, commands within a script would not be able to take advantage of using rights profiles, unless the script specified a profile shell as its first line. This rule required you to modify any scripts to use rights profiles, 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 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 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.