RHCSA

RHCSA – The “user”, “role” and “level” security attributes

Overview

By the end of this article you should be able to answer the following questions:

Announcement

You can find all my latest posts on medium.

What is the command to list all the available 'user' security attribute values?

$ seinfo –-user

What is the command to show the logic that SELinux uses to determine which of these values should be assigned for a newly created user?

$ semanage login -l

What is the command to list all the available 'role' security attribute values?

$ seinfo –-role

As mentioned before, the “targeted” policy primarily decides on granting access of one object to another object, based on the “type” security attributes, i.e it is a Type Enforcement based policy.

That means that that none of the other security attributes values matters that much.

The “user” security attribute

Eerlier we saw that are 4000+ possible values that a “type” security value can have, since that is the main one. In contrast there are less than 10 possible values that a “user” selinux attribute can have:

$ seinfo -u

Users: 8
   sysadm_u
   system_u
   xguest_u
   root
   guest_u
   staff_u
   user_u
   unconfined_u

However the targeted policy still has to assign a user security context value when a user is created. Here are the policy rules in the targeted policy, to help it determine what user security attribute value is assigned to a newly created user.

$  semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          unconfined_u         s0-s0:c0.c1023       *
root                 unconfined_u         s0-s0:c0.c1023       *
system_u             system_u             s0-s0:c0.c1023       *

Notice that system_u is for any service accounts that are created during an rpm package install. These service accounts will trigger processes, and these processes will inherit the initiating user’s security attribute values, which explains this:

$ ps -efZ | grep "httpd"
system_u:system_r:httpd_t:s0    root      1304     1  0 07:20 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0    apache    1407  1304  0 07:20 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0    apache    1408  1304  0 07:20 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0    apache    1409  1304  0 07:20 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0    apache    1410  1304  0 07:20 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
system_u:system_r:httpd_t:s0    apache    1411  1304  0 07:20 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

Inheriting security attribute values is the default unless the targeted policy specifies otherwise.

Also notice that the default “user” security attribute value for creating a new user is “unconfined_u”. You can modify this table so that when you create a user account with a certain name, then it adopts a different “user” security attribute value. Not sure how to do this yet.

The “role” security attribute

The role security attribute is used for using Roles Based Access Control (RBAC). The targeted policy works by stating with users can access which roles, and in turn, which roles can access which domains.

$ seinfo -r

Roles: 14
   auditadm_r
   dbadm_r
   guest_r
   staff_r
   user_r
   logadm_r
   object_r
   secadm_r
   sysadm_r
   system_r
   webadm_r
   xguest_r
   nx_server_r
   unconfined_r

Note, “system_r” is usually reserved for system processes. The same goes for system_u, which we saw earlier. They usually both go hand-in-hand.

roles are hardly used.

The “level” security attribute

This is something that is exclusive to the MLS policy type is hardly ever used. It is something that you don’t need to know about for the red hat exams.

CodingBee