Under the hood of Targeted Policy

To understand any SELinux policy, use the informative command—seinfo.

[root@vbg ~]# seinfo

Statistics for policy file: /etc/selinux/targeted/policy/policy.21

Policy Version & Type: v.21 (binary, MLS)

Classes:            61    Permissions:       220

Types:            1513    Attributes:        148

Users:               3    Roles:               6

Booleans:          210    Cond. Expr.:       186

Sensitivities:       1    Categories:       1024

Allow:           82518    Neverallow:          0

Auditallow:         28    Dontaudit:        5086

Role allow:          5    Role trans:          0

Type_trans:       1398    Type_change:        17

Type_member:         0    Range_trans:        23

Constraints:        47    Validatetrans:       0

Fs_use:             15    Genfscon:           64

Portcon:           264    Netifcon:            0

Nodecon:             8    Initial SIDs:       27

seinfo is a policy query tool that queries policy files and provides vital information about it. When executed without any arguments, it queries the default loaded policy file.

As you can see the policy file read by the seinfo tool by default is /etc/selinux/targeted/policy/policy.21. Installed by the selinux-policy-targeted RPM, this file contains the binary Targeted Policy.

The second line of the above output mentions that this is a binary policy with MLS (Multi Level Security). We will come to MLS in the later part of this series.

Now comes the interesting part of the output. You can clearly see various components of the policy. We will discuss these components in the course of these articles. Let us concentrate on a few important ones right now.

A typical security context as we discussed in Part 1 of this series, is of the type:

User Identity:Role:Type/Domain

As we can see from the above, in the default SELinux Targeted policy, there are:

1. Users (3 in number)
2. Roles (6 in number)
3. Types (1,513 in number)

This means that any object or subject in the SELinux Policy installed in the system can have one of three user identities, one of six roles and one of the available 1,513 types.

To list user identities defined in the SELinux Targeted Policy, run the following command:

[root@vbg ~]# seinfo -u

Users: 3

system_u

root

user_u

Do check all possible security contexts for objects (files, dirs, etc) and subjects (processes) in your system. The user identitity component of the Security context will have one of the above three identities and nothing else.

Similarly, to check the available roles, use the following code:

[root@vbg ~]# seinfo -r

Roles: 6

staff_r

user_r

object_r

secadm_r

sysadm_r

system_r

And please check the available list of types yourself by using the command given below:

[root@vbg ~]# seinfo -t

Thus we now know that any existing object or subject in the system will have a security context created out of these three users, six roles and 1,513 types.

You can alter the security context of any object by using the chcon command.

To change the type of an object, use chcon -t. To change the user identity, use chcon -u and chcon -r for role.

To test the above, create an empty file “context” in the /tmp directory and check its default security context:

[root@vbg ~]# touch /tmp/context

[root@vbg ~]# ls -lZ /tmp/context

-rw-r--r--  root root user_u:object_r:tmp_t:s0         /tmp/context

To change the type of this object from tmp_t to unconfined_t, use the code below:

[root@vbg ~]# chcon -t unconfined_t /tmp/context

[root@vbg ~]# ls -Z /tmp/context

-rw-r--r--  root root root:object_r:unconfined_t:s0    /tmp/context

I leave it as an exercise for you to change the role and the user for this object. If you face any issues, feel free to contact me at the e-mail ID provided below.

Assuming that, as above, you have changed the security context of an object quite a few times and you would like to revert back to the original/default security context, restorecon comes to the rescue.

restorecon restores files to their default security contexts. The verbose option of the restorecon command also displays the changes made in the security context. To check the usage of this very handy command, look at the example below:

[root@vbg ~]# touch /home/vbg/test-context

[root@vbg ~]# ls -Z /home/vbg/test-context

-rw-rw-r--  vbg vbg

user_u:object_r:user_home_t:s0         /home/vbg/test-context

[root@vbg ~]# chcon -t tmp_t /home/vbg/test-context

[root@vbg ~]# ls -Z /home/vbg/test-context

-rw-rw-r--  vbg vbg user_u:object_r:tmp_t:s0         /home/vbg/test-context

[root@vbg ~]# restorecon -v /home/vbg/test-context

restorecon reset /home/vbg/test-context context user_u:object_r:tmp_t:s0->user_u:object_r:user_home_t:s0

[root@vbg ~]# ls -Z /home/vbg/test-context

-rw-rw-r--  vbg vbg user_u:object_r:user_home_t:s0   /home/vbg/test-context

The above snippet shows the utility of the restorecon command. It reads the default contexts to be applied from the policy files and applies the default security context to a file/directory object.

A word of caution when using restorecon: DO NOT use the command with the -r (recursive) option. It may overwrite the security contexts of some important files in the system that you may have changed.

If you think that you have spoilt the security contexts of the files in your system beyond recovery, do not panic. Help is available in the form of Auto-Relabel, at boot. Simply create an empty file /.autorelabel. Please note that it is a hidden file.

[root@vbg ~]# touch /.autorelabel

[root@vbg ~]# reboot

Following the procedure mentioned above will cause SELinux to relabel the files on your system upon rebooting. Please use this to fix any improper security context on files and directories.

You can also use the fixfiles command to achieve the above. fixfiles can prevent you from rebooting your system but may not be as effective. Depending on the options and time available, you can choose any option that suits you—though I would suggest the reboot option.