RBAC

Role-Based Access Control (RBAC) was first introduced in Solaris 8 as a means of defining roles for managing a specific task or set of tasks, based on a set of administrator-defined profiles. Although the RBAC implementation supplied with Solaris is a Sun-specific product, it is based on a standard developed by NIST (see http://csrc.nist.gov/rbac/ for more information). Broadly defined, access control extends beyond the notion of administrative access. It can be defined as the ability to create, read, update, and delete data from a system. Standard file system permissions are based on this principle: various users and groups have access permissions to data stored in files based on a permission string that is associated with every file on the file system. However, although file access can be easily demarcated along organizational lines, deciding who should and who should not have administrative access to execute applications can be a more complex issue. What if a secretary needs to have root access to a system to add or delete users as they join an organization? Data entry of this kind seems like a reasonable task for a secretary, but it is usually assigned to system administrators because it requires root access. RBAC allows tasks like these to be separated from other tasks that do require a high level of technical knowledge, such as managing metadevices.

Roles

The first stage of implementing RBAC is to define roles, which are then assigned to individual users. Access rights to various resources can then be associated with a specific role name. As with any organization, the change to roles and the users associated with roles is inevitable, so the process for reflecting these changes in the list of roles and users needs to be as easy to implement as possible. In addition, individual tasks are not always easy to associate with a single role: indeed, in a large organization, some tasks will be performed by a number of different employees.

Caution

It’s also possible to assign specific authorizations to specific users—bypassing roles—but this defeats the whole “role-based” purpose of RBAC and is not recommended.

One way of dealing with task overlap is to introduce the notion of hierarchies. Profiles and authorizations at the bottom of a conceptual hierarchy are “inherited” by the assignment of a role at a higher level. For example, a role defined as “backup maintainer” involves running ufsdump, which in turn requires write access to the tape device. Thus, the backup role inherently requires access to lower level profiles for which new roles do not need to be separately defined. Another role, such as “device manager,” may also require write access to the tape device, through the tapes command. Again, no separate role is required to be created for those tasks that form part of the role by inference. However, although Solaris RBAC does support hierarchies of profiles and authorizations, it does not support hierarchies of roles. When a user assumes a role, the effect is all or nothing: No inheritance of roles is allowed.

By default, Solaris 9 supports three different system management roles:

A Primary Administrator (PA) Assigns rights to other users and is responsible for security.
A System Administrator (SA) Responsible for day-to-day administration that is not security-related.
An Operator Performs backups and device maintenance.

Figure 28-1 shows the hierarchy of rights associated with the different roles. The distinction between PA and SA will depend on the local security policy. For example, whereas the default PA role permits both adding users and changing passwords, the default SA role does not permit password modifications. However, for many sites, denying an SA access to passwords would be impractical. One of the great benefits of RBAC is that the rights granted to different profiles can be easily modified and customized to suit local requirements. Parallels can be drawn with Trusted Solaris and the assignment of tasks with different levels of authority to completely different roles.

Figure 28-1: Hierarchy of rights associated with the different roles.

Profiles

Associated with the concept of overlapping roles are the notions of authority and operational responsibility. Two individuals may carry out operations using similar roles, but for entirely different purposes. For example, a clerk in a supermarket may be allowed to enter cash transactions into the cash register, but only a supervisor can void transactions already entered. Conversely, a supervisor cannot enter cash transactions because the organizational requirements mandate a separation of supervisory and procedural roles, even though both operate on the same set of data and devices. Clearly, these roles and their associated operations must be defined “offline” before being implemented using the Solaris RBAC facility.

A profile is a specific command or set of commands for which an authorization can be granted. These authorizations are linked together to form a role, which is in turn associated with a single user or a number of different users, as shown in Figure 28-2. Profiles can be executed several ways:

The new pfexec command can be used to execute a single command contained in a profile.
Commands in profiles can be executed through new, restricted versions of the standard shells, such as pfsh (profile Bourne shell) and pfcsh (profile C shell).

Figure 28-2: Profiles and authorizations are associated with roles that are granted to individual users.

A new user account for each role can be created, with its own home directory and password. To execute commands contained in a profile, users who have access to the role can just su to the new account—they are not allowed to log in directly. Note that if two users su to the same role account, they will both be operating on the same files and could potentially overwrite each other’s data. The same is true for the normal root account. However, one difference between using su to access a role and using su to access a normal account is auditing—all of the operations carried out when using su to access a role are logged with the user’s original UID. Thus, the operations of individual users who access roles can be logged (and audited) distinctively.

Authorizations

Let’s look more closely at authorizations before examining how they are assigned to different roles. An authorization is a privilege that is granted to a role to allow operations to be performed, and that is defined in the file /etc/security/auth_attr. Some applications allow RBAC authorizations to be checked before allowing an action to be performed, including the device management commands (for example, allocate and deallocate), as well as the batch processing commands (for example, at, crontab). Authorizations have a form similar to Internet domain names: reading from left to right, the company name is followed by more specific package and function information. For example, net.cassowary.* is an authorization that pertains to any function supplied by the vendor cassowary.net. By default, all Solaris packages are identified by the prefix "solaris." Thus, the authorization for changing passwords is identified as solaris.admin.usermgr.pswd rather than the longer com.sun.solaris.admin.usermgr.pswd. Many authorizations are fine-grained, allowing read access but not write access, and vice versa. For example, a Primary Administrator may have the solaris.admin.usermgr.read and solaris.admin.usermgr.write authorizations that allow read and write access to user configuration files respectively. However, an SA may only be granted the solaris.admin .usermgr.read authorization but not the solaris.admin.usermgr.write authorization, effectively preventing him or her from changing the contents of user configuration files even if they have read access to the same files. The following examples show some of the common solaris.admin authorizations currently defined:

solaris.admin.fsmgr.:::Mounts and Shares::
solaris.admin.fsmgr.read:::View Mounts and Shares::help=AuthFsmgrRead.html
solaris.admin.fsmgr.write:::Mount and Share Files::help=AuthFsmgrWrite.html
solaris.admin.logsvc.:::Log Viewer::
solaris.admin.logsvc.purge:::Remove Log Files::help=AuthLogsvcPurge.html
solaris.admin.logsvc.read:::View Log Files::help=AuthLogsvcRead.html
solaris.admin.logsvc.write:::Manage Log Settings::help=AuthLogsvcWrite.html
solaris.admin.serialmgr.:::Serial Port Manager::
solaris.admin.usermgr.:::User Accounts::
solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html
solaris.admin.usermgr.read:::View Users and Roles::
  help=AuthUsermgrRead.html
solaris.admin.usermgr.write:::Manage Users::help=AuthUsermgrWrite.html

We can see that several authorizations have been defined for solaris.admin, including file system management (fsmgr), logging system management (logsvc), port management (serialmgr), and user management (userxmgr). The corresponding help files are also listed.

An important aspect of authorizations is the capability to transfer permissions to other users by using the grant keyword. Once grant is attached to the end of an authorization string, it enables the delegation of authorizations to other users. For example, the solaris.admin.usermgr.grant authorization, in conjunction with solaris.admin.usermgr.pswd, allows password changing to be performed by a delegated user.

How do roles, profiles, and authorizations fit together? Figure 28-3 attempts to show the flow of data from the definition of authorizations and command definition through to the association of authorizations to specific profiles, which are in turn utilized by users who have been assigned various roles. The sense in which RBAC abstracts users from directly using commands and authorizations is shown by the dotted lines in the diagram. In this diagram, it is easy to see how central roles are in systems where profiles for different tasks are well defined.

Figure 28-3: Integrating roles, profiles, and authorizations.