Role-Based Access Control (RBAC)

Role-based access control (RBAC) is a method that allows and restricts access to subjects or users based on the role of the user. When reading, pay attention to the description of an RBAC system and be able to describe the system, as well as to name the user that only RBAC can restrict. How does this one restriction increase the difficulty for an attacker to compromise the system? What is the set of rules called that manages the RBAC system? Although you will not be asked to create an RBAC policy, read through the rest of the document and try to follow the examples of how an RBAC policy is coded on a system.

5. Roles


Roles exist essentially as a container for a set of subjects, put to use in specific scenarios. There exist user roles, group roles, a default role, and special roles. See Flow of Matches to see how a role gets matched with a particular process.

 

User Roles

In a simplified form, user roles are roles that are automatically applied when a process either is executed by a user of a particular UID or the process changes to that particular UID. In the RBAC system, the name of a user role must match up with the name of an actual user on the system.

A user role looks like:

role user1 u

 

Group Roles

As with user roles, group roles pertain to a particular GID. The name of the group role must match up with the name of an actual group on the system. Note that this is tied only to the GID of a process, not to any supplemental groups a process may have. Group roles are applied for a given process only if a user role does not match the process' UID.

A group role looks like:

role group1 g

 

Default Role

If neither a user or group role match a given process, then it is assigned the default role. The default role should ideally be a role with nearly no access to the system. It is configured in such a way if full system learning is used.

A default role looks like:

role default

 

Special Roles

Special roles are to be used for granting extra privilege to normal user accounts. Some example uses of special roles are to provide an "admin" role that can restart services and edit system configuration files. Special roles can also be provided for regular users to keep their accounts more secure. If they have their own public_html directory, the user role for the user could keep this directory read-only, while a special role to which the user is allowed to transition could allow modification of the files in the directory.

Special roles come in two flavors, ones that require authentication, and ones that do not. On the side of special roles that require authentication, the RBAC system supports a flag that allows PAM authentication to be used for the special role. See Role Modes for a list of all these flags.

Special roles by themselves won't do anything unless there exist non-special (user, group, or default) roles that can transition to them. This transitioning is defined by the role_transitions rule, described in the Role Attributes page.

To authenticate to a special role, use gradm -a <rolename>. To authenticate with PAM to a special role, use gradm -p <rolename>. To transition to a special role that requires no authentication, use gradm -n <rolename>.

Special roles look like:

role specialauth s
role specialnoauth sN
role specialpamauth sP