The shell that a process runs in, the scope of the naming service, and the order of search can affect whether assigned rights are evaluated. Processes whose rights cannot be evaluated fail. For assistance in checking for rights assignments, see Troubleshooting RBAC and Privileges.
Users and roles can run privileged applications from a profile shell. A profile shell is a special shell that recognizes rights. Administrators can assign a profile shell to users as a login shell, or the profile shell is started when a user runs the pfexec command or the su command to assume a role. In Oracle Solaris, every shell has a profile shell counterpart. For a list of profile shells, see the pfexec(1) man page.
Users who are directly assigned a rights profile and whose login shell is not a profile shell must open a profile shell to run the privileged commands that they are assigned. Users and roles who are assigned an authenticated rights profile are prompted to authenticate, that is, to provide a password before the command can execute. For usability and security considerations, see Considerations When Assigning Rights.
Name service scope affects when assigned rights are available. The scope of a role might be limited to an individual host. Alternatively, the scope might include all hosts that are served by a naming service such as LDAP. The name service scope for a system is specified in the name switch service, svc:/system/name-service/switch. A lookup stops at the first match. For example, if a rights profile exists in two name service scopes, only the entries in the first name service scope are used. If files is the first match, then the scope of the role is limited to the local host. For information about naming services, see the nsswitch.conf(5) man page, Working With Oracle Solaris 11.4 Directory and Naming Services: DNS and NIS, and Working With Oracle Solaris 11.4 Directory and Naming Services: LDAP.
A user or role can be assigned security attributes directly or through a rights profile. The order of search affects which security attribute value is used. The value of the first found instance of the attribute is used.
When a user logs in, rights are assigned in the following search order:
Rights that are assigned directly to the user with the useradd and usermod commands. For a list of possible rights assignments, see user_attr Database.
Rights profiles that are assigned to the user with the useradd and usermod commands. These assignments are searched in order.
The order is the first profile in the authenticated profiles list and then its supplementary profiles, the second profile in the authenticated profiles list and then its supplementary profiles, and so on. The first instance of a value is the one that the system uses, except for auths values, which are cumulative. The attributes that can be assigned to rights profiles include all the rights that can be assigned to users, plus supplementary profiles. For the list, see user_attr Database.
Then, the rights profiles that do not require reauthentication are searched in the same fashion.
Console User rights profile value. For a description, see Rights Profiles Reference.
If the Stop rights profile is assigned, the evaluation of security attributes stops. No attributes are assigned after the Stop profile is assigned. The Stop profile is evaluated after the Console User rights profile and before the other security attributes, including authorizations_granted. For a description, see Rights Profiles Reference.
rbac/default_profiles astring Basic\ Solaris\ User
Applications and commands that can override system controls are considered privileged applications. Security attributes such as UID=0, privileges, and authorizations make an application privileged.
Privileged applications that check for root (UID=0) or some other special UID or GID have long existed in the UNIX environment. The rights profile mechanism enables you to isolate commands that require a specific ID. Instead of changing the ID on a command that anyone can access, you can place the command with an assigned UID in a rights profile. A user or role with that rights profile can then run the program as that UID without having to become superuser.
IDs can be specified as real or effective. Assigning effective IDs is preferred over assigning real IDs. Effective IDs are equivalent to the setuid feature in the file permission bits. Effective IDs also identify the UID for auditing. However, because some shell scripts and programs require a real UID of root, real UIDs can be set as well. For example, the reboot command requires a real rather than an effective UID.
Privileged applications can check for the use of privileges. The rights profile mechanism enables you to specify the privileges for specific commands that require security attributes. Then, you can isolate the command with assigned security attributes in a rights profile. A user or role with that rights profile can then run the command with just the privileges that the command requires.
Kerberos commands, such as kadmin, kprop, and kdb5_util
Network commands, such as ipadm, routeadm, and snoop
File and file system commands, such as chmod, chgrp, and mount
Commands that control processes, such as kill, pcred, and rcapadm
To add commands with privileges to a rights profile, see How to Create a Rights Profile and the profiles(1) man page. To determine which commands check for privileges in a particular profile, see Listing Rights in Oracle Solaris.
Audit administration commands, such as auditconfig and auditreduce
Printer administration commands, such as cupsenable and lpadmin
Batch job commands, such as at, atq, batch, and crontab
Device-oriented commands, such as allocate, deallocate, list_devices, and cdrw.
For guidance about checking a script or program for authorizations, see Example 40, Checking for Authorizations in a Script or Program. To write a program that requires authorizations, see About Authorizations in Developer’s Guide to Oracle Solaris 11.4 Security.