SELinux RBAC is used to be able to assign several SELinux restricted environments to a single SELinux user.

SELinux User Roles are User Domains. When i refer to roles i often mean a SELinux Users' secondary User Domain. Often roles that were designed to be secondary User Domains differ from primary User Domains. This is because Linux Users do not actually use the roles that were designed to be secondary User Domains to log into the system.

Instead Linux users Domain Transition to their secondary role by using the sudo command or a combination of the su and newrole command.

Keep in mind that some roles were designed to be primary User Domains and other roles only support secondary User Domain functionality. Primary User Domains let a user log into the system and secondary User Domains can only be used with the sudo and su with newrole command.

Sysadm Role - An example of a role that is designed to be a primary User Domain:

The sysadm_u SELinux User is mapped to the sysadm_r role. This mapping can be listed by running: sudo semanage user -l | grep sysadm_u

The staff_u SELinux User is also mapped to the sysadm_r role. The primary User Domain for the staff_u SELinux user is staff_r role. The default contexts configured in /etc/selinux/targeted/contexts/users/staff_u define what User Domains users should be logged in with by default, and what User Domains users can log in with by for example specifying a User Domain to log in with.

By default a staff_u SELinux User logs into the system in the staff_t User Domain. The sysadm_r role which was designed to be a primary User Domain can optionally be used to log in by using for example: ssh joe/sysadm_r@localhost.localdomain.tld

The sysadm_r role can also be used to Domain Transition by running the sudo and su with newrole command the way secondary User Domains as accessed.

The sysadm_t User Domain is the default environment of operation for the sysadm_u SELinux User and is designed to be the secondary environment of operation for the staff_u SELinux User, but even the staff_u SELinux User can force the pam_selinux Pluggable Authentication Module to use sysadm_t as its primary User Domain.

Webadm Role - An example of a role that is designed to be a secondary domain:

Unlike the sysadm_r role, the webadm_t User Domain cannot be used to log in to the system directly. Instead it must be accessed from another User Domain with the sudo or su with newrole command. The webadm_t User Domain does not have the permissions required to run a full user environment.

To use the webadm_r role, it should be mapped to for example the staff_u SELinux user: sudo semanage user -m -L s0 -r s0-s0:c0-c1023 -R "staff_r system_r webadm_r" -P user staff_uPlease note that you are not encouraged to modify existing SELinux Users. It is preferred that the default SELinux Users are left in their original state. Instead add new customized SELinux Users:

sudo semanage user -a -L s0 -r s0-s0:c0-c1023 -R "staff_r system_r webadm_r" -P user webadm_u

The webadm_r role can only be used as a secondary User Domain for two reason in this example. The first reason is the the webadm_t User Domain does not have enough permissions to support a full login environment. The second reason this that the we have based our webadm_u default context file in /etc/selinux/targeted/contexts/users of off the staff_u default contexts file. In this file the webadm_t User Domain is not a valid context to use for system logins.

Using Roles to confine Root:

Role Based Access Control can be used to create different User Domains with different permissions and assign those roles to SELinux Users. Although RBAC can be used for both unprivileged and privileged users, it is common to use it to restrict the privileged root user.

The webadm_u SELinux user i create above for example can be used to restrict a Linux User with root access to only be able to manage the Apache environment. The staff_t User Domain is unprivileged. This means that if i run in the staff_t User Domain as root, then i will not be able to use the root powers. The webadm_t User Domain is a limited privileged User Domain. If i operate in the webadm_t User Domain as root then i can access root resources that are permitted by the webadm_t restricted environment.

For example, i, dgrift am mapped to the webadm_u SELinux User. I am also allowed all root permissions in the sudoers configuration file in /etc/sudoers. When i log into the system by default i will find myself in the staff_t User Domain. If i run the sudo command as staff_t then i will for example not be able to restart the Apache service.

If i use the sudo command to Domain Transition to webadm_t before restarting the service i will be able to succeed:

sudo -r webadm_r -t webadm_t service httpd restart

If i try to use the sudo command to change root password i will fail because neither staff_t nor webam_t User Domains have access to this privilege.

This is a powerful feature. It means that it is not possible to delegate limited specified root privileges without having to share roots password.

Next i will explain some of the pre-defined roles available:

The guest_r role:

The xguest_r role:

The user_r role:

The staff_r role:

The sysadm_r role:

The system_r role:

The unconfined_r role:

The webadm_r role:

The logadm_r role: