Log in

No account? Create an account

Previous Entry Share Next Entry
Understanding SELinux Roles
I received a container bugzilla today for someone who was attempting to assign a container process to the object_r role.  Hopefully this blog will help explain how roles work with SELinux.

When we describe SELinux we often concentrate on Type Enforcement, which is the most important and most used feature of SELinux.  This is what describe in the SELinux Coloring book as Dogs and Cats. We also describe MLS/MCS Separation in the coloring book.

Lets look at the SELinux labels
The SELinux labels consist of four parts, User, Role, Type and Level.  Often look something like


One area I do not cover is Roles and SELinux Users.

The analogy I like to use for the Users and Roles is around Russian dolls.  In that the User controls the reachable roles and the roles control the reachable types.

When we create an SELinux User, we have to specify which roles are reachable within the user.  (We also specify which levels are are available to the user.

semanage user -l

         Labeling   MLS/       MLS/                       
SELinux User    Prefix     MCS Level  MCS Range       SELinux Roles

guest_u             user       s0         s0                             guest_r
root                    user       s0         s0-s0:c0.c1023        staff_r sysadm_r system_r unconfined_r

staff_u               user       s0         s0-s0:c0.c1023        staff_r sysadm_r system_r unconfined_r
sysadm_u         user       s0         s0-s0:c0.c1023        sysadm_r
system_u          user       s0         s0-s0:c0.c1023        system_r unconfined_r
unconfined_u    user       s0         s0-s0:c0.c1023        system_r unconfined_r
user_u               user       s0         s0                             user_r
xguest_u           user       s0         s0                             xguest_r

In the example above you see the Staff_u user is able to reach the staff_r sysadm_r system_r unconfined_r roles, and is able to have any level in the MCS Range s0-s0:c0.c1023.

Notice also the system_u user, which can reach system_r unconfined_r roles as well as the complete MCS Range.  System_u is the default user for all processes started at boot or started by systemd.  SELinux users are inherited by children processes by default.

You can not assign an SELinux user a role that is not listed,  The kernel will reject it with a permission denied.

# runcon staff_u:user_r:user_t:s0 sh
runcon: invalid context: ‘staff_u:user_r:user_t:s0’: Invalid argument

The next part of the Russian dolls is roles.

Here is the roles available on my Fedora Rawhide machine.

# seinfo -r

Roles: 14


Roles control which types are available to a role.

# seinfo -rwebadm_r -x
      Dominated Roles:

In the example above the only valid type available to the webadm_r is the webadm_t.   So if you attempted to transition from webadm_t to a different type the SELinux kernel would block the access.

system_r role is the default role for all processes started at boot, most of the other roles are "user" roles.

seinfo -rsystem_r -x | wc -l

As you can see there are over 950 types that can be used with the system_r.

Other roles of note:

object_r is not really a role, but more of a place holder.  Roles only make sense for processes, not for files
on the file system.  But the SELinux label requires a role for all labels.  object_r is the role that we use to fill the objects on disks role.  Changing a process to run as object_r or trying to assign a different role to a file will always be denied by the kernel.

RBAC - Roles Based Access Control

SELinux Users and Roles are mainly used to implement RBAC.  The idea is to control what an adminsitrator can do on a system when he is logged in.  For certain activities he has to switch his roles.  For example, he might log in to a system as a normal user role, but needs to switch to an admin role when he needs to administrate the system.

Most of the other roles that are assigned above are user roles.  I have written about switching roles in the past when dealing with confined administrators and users.  I usually run as the staff_r but switch to the unconfined_r (through sudo) when I become the administrator of my system.

Most people who use SELinux do not deal with RBAC all that often, but hopefully this blog helps remove some of the confusion on the use of Roles.

  • 1
"Roles only make sense for processes, not for files on the file system."

This use to be true, but since policyversion 27 roles are no longer only usable with processes.
The libsemanage genhomedircon code was also recently adjusted to support associating roles with objects (version 2.6)

By associating roles with "objects", the can be used to achieve "per-role" separation. Effectively allowing for isolation of groups of Linux users/groups

Also good to know is that a single security attribute like for example roles can actually be used to address more than a single SELinux challenge at the same time. In this case RBAC and RBACSEP.

To make this series comprehensive. One should also explain IBAC (how SELinux identities are used to extend Linux Access Control with SELinux)

Interesting, please give links to blogs covering these issues.

Dear Daniel,

Great tutorial, where can I see the detail of each role, for example, what sort of access and or permission each role has I am particularly interested in sysadm_u. I know that I can manage the sudo commands from the sudoers file but I will like to leverage SELinux roles and possibly create a role that caters to a specific environment.

Thanks in advance

You can see the types associated with a role using
seinfo -rsysadm_r -x

RBAC in targeted policy

Dear Daniel,

Is RBAC really used in "targeted" policy? I read at some places that RBAC is not used in targeted policy but only Type Enforcement which is only used/considered during file/process access or context transition in targeted SELinux policy.

could you please confirm? And if used, please give some use cases.


Edited at 2019-08-04 06:26 pm (UTC)

Re: RBAC in targeted policy

If you are using confined users, then you are using RBAC. Particularly when you are running with staff_t user and able to switch to sysadm_r:sysadm_t or webadm_r:webadm_t.

Unconfined user/process role

Hi Daniel,

As I understand, SELinux is not enforced if user/process is "unconfined". I'm trying to change context of one of file with "root" user whose context is "unconfined_u:unconfined_r:unconfined_t:s0".

[root@localhost ~]# chcon -t crontab_t /var/www/html/index.html
chcon: failed to change context of ‘/var/www/html/index.html’ to ‘unconfined_u:object_r:crontab_t:s0’: Permission denied

audit.log error:
type=AVC msg=audit(1565450416.725:1018452): avc: denied { relabelto } for pid=29606 comm="chcon" name="index.html" dev="dm-1" ino=14897964 scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:object_r:crontab_t:s0 tclass=file
type=SYSCALL msg=audit(1565450416.725:1018452): arch=c000003e syscall=188 success=no exit=-13 a0=a1b0e0 a1=7fed8a91b77e a2=a1c650 a3=23 items=0 ppid=29513 pid=29606 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=56020 comm="chcon" exe="/usr/bin/chcon" subj=unconfined_u:unconfined_r:unconfined_t:s0 key=(null)

If "unconfined" user/process is ignored in "SELinux", then why changing permission of a file by "unconfined" user (root" is denied as given above log?

Re: Unconfined user/process role

You are being blocked because you are attempting to assign a PROCESS Type to a file type. In SELinux this makes no sense, so the policy will not allow it.

What was the original AVC that you decided to make this change for?

  • 1