Certification Objective 14.01Understanding Role-Based Access Control

Certification Objective 14.01—Understanding Role-Based Access Control

Exam Objective 4.1: Configure role-based access control (RBAC) including assigning rights profiles, roles, and authorizations to users.

Role-based access control (RBAC) is a security model that you, the superuser, can use for letting non-root users have access to tasks that would normally be restricted to superuser, the root account. You can use RBAC to apply security rights to processes and to users, and thereby distribute the security-related capabilities among several users, called administrators. This is accomplished through the following RBAC features: roles, rights profiles, and authorizations.

Understanding Roles

A role is a special type of account that can be associated with one or more users, and those users can subsequently assume that role; once they do, they assume all the rights assigned to the role. You create roles the same way you create normal user accounts, and just like a normal user account, a role has a home directory, a password, a group, and so on. The main characteristics of roles are described here:

• A user cannot initially log in as a role. Once logged into a normal user account, the user can assume a role by using the su (switch user) command (of course a role name and a password are required), or by using the SMC GUI.

• When a user assumes a role, all the user attributes are replaced with role attributes.

• Two or more users can assume the same role, and when they do, they have the same directory, access to the same files, the same operating environment, and so on.

• A user cannot assume more than one role at the same time. A user who has assumed a role must exit that role to be able to assume another role.

• The information about a role is stored in the passwd, shadow, and user_attr databases.

• Roles cannot inherit rights from other roles or users.

On the Job 

You can use roles to prevent a root login to your system from a remote machine. Just metamorphose the incoming root user into a role.

Note that assigning the role to a user and the user's assuming that role are two different things. Before a user can assume a role, the role must be assigned by the primary administrator (superuser) to that user.

The administrative capabilities are given to the roles by rights profiles and authorizations.

Understanding Rights Profiles

A rights profile is a collection of rights such as authorization, commands with assigned security attributes, and other rights profiles that can be assigned to a role. The rights profiles information is stored in the prof_attr and exec_attr databases.

Some typical rights profiles (and roles based on these rights profiles) are described here:

• Primary administrator. This rights profile consists of all the rights of a superuser.

• System administrator. This profile contains most of the rights except for security-related rights. It provides the ability to perform most non-security administrative tasks, such as printer management, cron management, device management, file system management, mail management, backup and restore, name service management, network management, software installation, and process and user management. However, it includes several other profiles, which makes it a powerful profile.

• Operator. This profile contains limited rights to manage files and offline media. It provides the ability to perform backups and printer maintenance. By default, it does not include the rights to restore files.

• Printer management. This profile consists of a limited number of authorizations and commands to handle printing.

• Basic Solaris user. This profile enables users to use the Solaris system within the security boundaries set up on the system. This profile is assigned, by default, to all the Solaris users.

• All. This profile consists of commands that do not have security attributes.

Note that these are typically used roles, and you can create profiles and roles based on those profiles according to the security needs of your organization. Although no roles are shipped with Solaris, there are three roles that can be easily configured: primary administrator, system administrator, and operator.

Roles are powered by profiles, and profiles are powered by authorizations.

Understanding Authorizations

An authorization is a discrete permission that enables a user (or a role) to perform a class of actions that could affect security. For example, the security policy gives ordinary users the Solaris.device.cdrw authorization at installation, which enables users to read and write to a CD-ROM device. The authorizations are listed in the /etc/security/auth_attr file.

Although an authorization can be directly assigned to a role or a user, in the RBAC model, it is typically assigned to a profile from which it flows to a role and subsequently to the user who assumes that role. Profiles can also include commands with security attributes and other profiles.

Figure 14-1 puts all the pieces together to give you an overall picture of RBAC.

Figure 14-1: Relationship between different elements of RBAC

A role is assigned to a user, and a user can assume only one role at a time; when a user does so, that user automatically acquires the capabilities of the role. Roles, in turn, get their capabilities from the rights profiles, which consist of authorizations, privileged commands, and other rights profiles. A privileged command is a command that executes with special permissions. A privilege is a discrete right that a process requires to perform an operation. You can also assign privileges to a user, a role, or a system. A process executing with privileges executes within the bounds of the system's security policy and eliminates the need for a call to setuid, which runs outside the bounds of the system security. Recall that setuid and setgid, which we discussed in Chapter 7, are security attributes that you can assign to a process to perform an operation that is otherwise forbidden to ordinary users.

The superuser model and the RBAC model can coexist on the same system. For example, you can log in as an ordinary user or as root and then assume a role. A comparison of the two models is presented in Table 14-1.

Table 14-1: Comparison of superuser and RBACK models (RBAC provides more options and flexibility)

User Capability on a System	Superuser Model	RBAC Model
Can become superuser with all superuser capabilities	Yes	Yes
Can log in as user with full user capabilities	Yes	Yes
Can log in as a user and acquire superuser capabilities	Yes, with setuid.	Yes, with setuid and using RDAC as well.
Once logged in as a user, can acquire limited superuser capabilities	No	Yes
Can log in as a user and acquire administrative capabilities but not full superuser capability	No	Yes
Can log in as a user and have fewer capabilities than an ordinary user	No	Yes

Now that you understand the different components of RBAC, it's time to explore how it is used.