This section provides more details about the implementation and use of rights at the user level.
An authorization is a right that can be granted to a role, a program, a zone, or a user. Authorizations enforce policy at the user application level. Like privileges, mistaken assignments of authorizations can result in more rights being granted than originally intended. For more information, see Privilege Escalation and User Rights.
The difference between authorizations and privileges concerns the level at which the security policy is enforced. Without the proper privilege, a process can be prevented from performing privileged operations by the kernel. Without the proper authorizations, a user can be prevented from using a privileged application or from performing security-sensitive operations within a privileged application. For a fuller discussion of privileges, see Process Rights Management.
Rights-compliant applications can check a user's authorizations prior to granting access to the application or specific operations within the application. This check replaces the check in conventional UNIX applications for UID=0.
For more information about authorizations, see the following sections:
A rights profile is a collection of rights that can be assigned to a role or user to perform tasks that require administrative rights. A rights profile can include authorizations, privileges, commands with assigned security attributes, and other rights profiles. Rights profiles can also contain entries to reduce or extend the initial inheritable set of privileges and to reduce the limit set.
An authenticated rights profile is a rights profiles that requires the user to supply a password, or to reauthenticate. The administrator decides which profiles can be used without user reauthentication. A good example of a profile that would not require reauthentication is the Basic Solaris User rights profile. Depending on site security requirements, rights profiles for security-sensitive tasks might require reauthentication.
For reference information about rights profiles, see the following sections:
A role is a special type of user account from which you can run privileged applications. Roles are created in the same general manner as user accounts. Roles have a home directory, a group assignment, a password, and so on. Rights profiles and authorizations give the role administrative rights. Roles cannot inherit rights from other roles or from the user who assumes the role. Roles distribute superuser privileges, and thus enable more secure administrative practices.
A role can be assigned to more than one user. All users who can assume the same role have the same role home directory, operate in the same environment, and have access to the same files. Users can assume roles at the command line by running the su command and supplying the role name and the role's password. The administrator can configure the system to enable a user to authenticate by supplying the user's password. See Example 18, Enabling a User to Use Own Password for Role Password.
A role cannot log in directly. A user logs in, and then assumes a role. Once you have assumed a role, you cannot assume another role without first exiting your current role.
Also, while a rights profile adds rights to the user's environment, a role gives the user a clean execution environment that is shared with other users who can assume that role. When a user switches to a role, none of the user's authorizations or rights profiles applies to the role.
The passwd, shadow, and user_attr databases store static role information. You can and should audit the actions of roles.
For detailed information about setting up roles, see the following sections:
The fact that root is a role in Oracle Solaris prevents anonymous root login. If the profile shell command, pfexec, is being audited, the audit trail contains the login user's real UID, any roles that the user has assumed, and the privileged operations that were performed. To audit the system for privileged operations, see Auditing Administrative Actions.
Qualified user attributes are attributes that can be assigned to users and roles, and to hosts and groups of hosts called netgroups. Netgroups simplify administration of a set of systems, such as a lab network. These qualifiers apply only to LDAP accounts, not to the files naming service.
Qualified and unqualified user attributes are maintained independently, and cannot be combined. This independence allows administrators to assign both qualified and unqualified extended policy attributes to a single user or role. At runtime, the system first determines the hostname where the execution is occurring, then applies the appropriate set of policy attributes.
The usermod and rolemod commands accept a qualifier option, -q to indicate the host or netgroup where the security attributes apply. Separate usermod and rolemod commands are required to manage each set of qualified or unqualified attributes. The userdel and roledel commands can remove a complete set of qualified attributes without affecting other qualified or unqualified attributes.
The policy for applying the appropriate set of user attributes follows the search order specified by the name-service/switch service and is cached by the name-service/cache service. The order is:
A local entry matching the named user or role
One or more LDAP entries of the named user or role's qualified attributes
An LDAP entry whose hostname matches the current host
A netgroup (in LDAP) that has the current host as a member
An unqualified entry for the named LDAP user or role
In the absence of an assigned Stop rights profile, default attributes specified in the account-policy service. The attribute values in the policy.conf file usually reflect the service values.
If a match is found, it is cached to optimize subsequent queries. For examples, see Example 33, Qualifying Where and When LDAP Users and Roles Can Use Their Rights.