Role-Based Access Control (Overview)
This chapter describes role-based access control (RBAC), a security feature for controlling access to tasks that would normally be restricted to superuser. This is a list of the overview information in this chapter.
For information on RBAC tasks, see Chapter 18, Role-Based Access Control (Tasks). For reference information on the RBAC elements and tools, see Chapter 19, Role-Based Access Control (Reference).
RBAC: Replacing the Superuser Model
In conventional UNIX systems, the root user (also referred to as superuser) is all-powerful, with the ability to read and write to any file, run all programs, and send kill signals to any process. Effectively, anyone who can become superuser can modify a site's firewall, alter the audit trail, read payroll and other confidential records, and shut down the entire network.
Role-based access control (RBAC) is an alternative to the all-or-nothing superuser model. RBAC uses the security principle of least privilege, which is that no user should be given more privilege than necessary for performing his or her job. RBAC allows an organization to separate superuser's capabilities and assign them to special user accounts that are called roles. Roles can be assigned to specific individuals, according to their job needs.
The flexibility in setting up roles enables a variety of security policies. Three recommended roles that can be easily configured are available:
Primary Administrator - A powerful role that is equivalent to root.
System Administrator - A less strong role for administration that is not related to security. This role does not allow the user to set passwords.
Operator - A junior administrator role for operations such as backups and restores, and printer management.
There is no requirement that these specific roles be implemented. Roles are a function of an organization's security needs. Roles can be set up for special-purpose administrators in areas such as security, networking, or firewall administration. Another strategy is to create a single strong administrator role along with an advanced user role for those users who are permitted to fix portions of their own systems.
Solaris RBAC Elements
In the RBAC model in the Solaris operating environment, users log in as themselves and assume roles that enable them to run restricted administration graphical tools and commands. The RBAC model introduces these elements to the Solaris operating environment:
Privileged Application - An application that can override system controls and check for specific user IDs (UIDs), group IDs (GIDs), or authorizations (see "Privileged Applications").
Role - A special identity for running privileged applications that can be assumed by assigned users only.
Authorization - A permission that can be assigned to a role or user (or embedded in a rights profile) for performing a class of actions that are otherwise prohibited by security policy.
Rights Profile - A collection of overrides that can be assigned to a role or user. A rights profile can consist of authorizations, commands with setuid or setgid permissions (referred to as security attributes), and other rights profiles.
The following figure shows how the RBAC elements work together.
Figure 17-1 Solaris RBAC Element Relationships
In RBAC, users are assigned to roles. Roles get their capabilities from rights profiles and authorizations. Authorizations are generally assigned to the rights profiles with which they are logically associated but can be assigned directly to roles.
Note - Rights profiles and authorizations can also be assigned directly to users. This practice is discouraged because it enables users to make mistakes through inadvertent use of their privileges.
Commands with security attributes, that is, real or effective UIDs or GIDs, can be assigned to rights profiles.
The following figure uses the Operator role and the Printer Management rights profiles as examples to demonstrate RBAC relationships.
Figure 17-2 How Solaris RBAC Elements Relate
The Operator role is used to maintain printers and perform media backup. The user johnDoe is assigned to the Operator role and can assume it by supplying the Operator password.
The Operator rights profile has been assigned to the Operator role. The Operator rights profile has two supplementary profiles assigned to it, Printer Management and Media Backup, which reflect the Operator role's primary tasks.
The Printer Management rights profile is for managing printers, print daemons, and spoolers. Three authorizations are assigned to the Printer Management rights profile: solaris.admin.printer.read, solaris.admin.printer.delete, and solaris.admin.printer.modify. These authorizations allows users to manipulate information in the printer queue. The Printer Management profile also has a number of commands with security attributes that are assigned to it, such as /usr/sbin/accept with euid=0 and /usr/ucb/lpq with euid=lp.
Privileged Applications
Applications that can override system controls are considered privileged applications.
Applications That Check UIDs and GIDs
Privileged applications that check for root or some other special UID or GID have long existed in UNIX. The RBAC rights profile mechanism enables you to specify the UID or GID for specific commands. Instead of changing the ID on a command that anyone can access, you can isolate the command with execution security attributes in the rights profile. A user or role with that rights profile can then run the program without having to become root.
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 and identify the UID for auditing. However, because some shell scripts and programs require a real UID of root, real IDs can be set as well. For example, the pkgadd command requires a real rather than an effective UID. If you encounter a command where the effective UID is not sufficient to run the command, you need to change the privilege to a real UID by using the Set Security Attributes option in the SMC Right Properties dialog boxes as described in "Creating or Changing a Rights Profile".
Applications That Check Authorizations
RBAC additionally provides commands that check authorizations. By definition, root has all authorizations and thus can run any application. Currently, the applications that check for authorizations include the following:
The entire Solaris Management Console suite of tools
The batch job-related commands - at, atq, batch, and crontab
Device-oriented commands - allocate, deallocate, list_devices, and cdrw.
Profile Shell
Authorized users can obtain privileged applications from the Solaris Management Console launcher or on the command line from a profile shell. A profile shell is a special kind of shell that enables access to the privileged applications that are assigned to the profile. Profile shells are launched when the user runs su to assume a role. The profile shells are pfsh, pfcsh, and pfksh. They correspond to Bourne shell (sh), C shell (csh), and Korn shell (ksh), respectively.
RBAC Roles
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, with a home directory, groups, password, and so on. The capabilities of a role are a function of the rights profiles and authorizations that are assigned to it. Roles do not have inheritance.
When a user assumes a role, the role's attributes replace all user attributes. Role information is stored in the passwd, shadow, user_attr, and audit_user databases. For detailed information on setting up roles, see "Configuring Recommended Roles", "Creating Roles", and "Changing Role Properties".
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 from the command line by running su and supplying the role name and password. Users can also assume a role when they open a Solaris Management Console tool.
Users cannot log in directly to a role. For this reason, it is useful to make root a role to prevent anonymous root login. See "Making Root a Role". Users must log in to their user account first. A user cannot assume a role directly from another role. A user's real UID can always be audited.
No predefined roles are shipped with the Solaris 9 software. As stated earlier in this chapter, you can easily configure the three recommended roles.