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. The following is a list of the overview information in this chapter.

• RBAC: Replacing the Superuser Model

• Solaris RBAC Elements

• Privileged Applications

• RBAC Roles

• RBAC Authorizations

• RBAC Rights Profiles

• Name Service Scope

For information on RBAC tasks, see Chapter 6, Role-Based Access Control (Tasks). For reference information on the RBAC elements and tools, see Chapter 7, 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 5-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 5-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.