Overview
By the end of this article you should be able to answer the following questions:
$ seinfo –-user
$ semanage login -l
$ 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.