SELinux Lockdown Part Five: SELinux RBAC

It was explained in part one of this series that SELinux users are mapped to SELinux User Domains and Multi Category Security Components. These mappings can be configured by running the semanage command with the user option, and the SELinux User mappings can also automatically be configured by calling the gen_user() interface in the Type Enforcement Source Module file for your User Domain.

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

Linux Users that are mapped to the sysadm_u SELinux User operate in the sysadm_r role by default. In this case sysadm_r is a primary User Domain.

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_u

Please 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
cp /etc/selinux/targeted/contexts/users/staff_u /etc/selinux/targeted/contexts/users/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:
This is a primary User Domain only. See part one in this series for a explanation of the guest_u SELinux user.

The xguest_r role:
This is a primary User Domain only. See part one in this series for a explanation of the xguest_u SELinux user.

The user_r role:
This is a primary User Domain only. See part one in this series for a explanation of the user_u SELinux user.

The staff_r role:
This is a primary User Domain only. See part one in this series for a explanation of the staff_u SELinux user.

The sysadm_r role:
This User Domain can be used as both primary as well as secondary User Domain. The sysadm_u SELinux Users uses sysadm_r as its default role and the staff_u SELinux user uses sysadm_r as its optional role. The sysadm_r role has permissions sufficient for user logins. See part one in this series for a explanation of the sysadm_u user.

The system_r role:
This role is used by the system as a primary role. Users can use the system_r role as a secondary role to restart system services in their proper context.

The unconfined_r role:
This User Domain can be used both as primary as well as secondary User Domain. See part one in this series for a explanation of the unconfined_u user.

The webadm_r role:
This User Domain can be used as secondary User Domain only. This role has does not have access to user home directories and many other privileges required by login users. This User Domain has the permission required to manage the Apache environment.

The logadm_r role:
This User Domain can be used as secondary User Domain only. This role has does not have access to user home directories and many other privileges required by login users. This User Domain has the permission required to manage the logging environment.

Refer: man newrole, man su, man sudo, man semanage