Understanding SELinux modes
Irrespective of the policy or the rules implemented through SELinux Type Enforcement, there are three modes of operation for SELinux:
- Disabled
- Permissive
- Enforcing
Disabled mode implies that SELinux is disabled and not implemented on the host. This has been the most common choice in installations seen by me. Hopefully, by the end of this series, we shall be able to bring about a change in that practice by encouraging more system administrators to adopt SELinux.
Permissive mode is similar to Debugging Mode. In Permissive Mode, SELinux policies and rules are applied to subjects and objects, but actions ( for example, Access Control denials) are not effected. The biggest advantage of Permissive Mode is that log files and error messages are generated based on the SELinux policy implemented.
In other words, if the SELinux policy would prevent the
httpd subject (Apache Web server) from accessing the object folder /webdata/ on my system, implementing SELinux in Permissive Mode would let the Apache Web server access the folder /webdata/ but log a denial in the log files.
This error logging informs the system administrator that if SELinux is activated in the Enforcing Mode, the
httpd subject would be disallowed access to the /webdata/ folder on my system.
Permissive Mode is the initiating point for all those wanting to explore the world of Type Enforcement through SELinux. Without blocking access to your favourite programs such as OpenOffice.org, Evolution, etc, it provides you with enough debugging information to fine tune your policy before deploying it on your system.
Enforcing Mode, as the name signifies, is SELinux in action. All production systems, when hardened, should enable SELinux in Enforcing Mode. SELinux through Access Controls does have a minor performance overhead, but compared to the advantages that it brings to the table, I am sure it will soon become the norm to implement SELinux on production servers.
Controlling SELinux
The
getenforce command gets the current mode of SELinux. It reports whether SELinux is Enforcing, ermissive, or Disabled.
On a system with SELinux disabled, it will display the following:
[root@station20 ~]# getenforce Disabled
On a system with SELinux in Permissive Mode, it will display:
[root@vbg ~]# getenforce Permissive
On a system with SELinux in Enforcing Mode, the following will be displayed:
[root@vbg ~]# getenforce Enforcing
setenforce modifies the mode SELinux is running in. It is used to toggle between Permissive and Enforcing mode when SELinux is enabled.
To activate “Enforcing mode” on an SELinux-enabled system, run:
[root@vbg ~]# setenforce 1
To check the current status, use
getenforce. To activate Permissive SELinux mode, execute:[root@vbg ~]# setenforce 0
The
sestatus command is used to get the status of a system running SELinux. Apart from mentioning the current mode of SELinux, it gives more information about the SELinux policy.
On a system with SElinux disabled, it will display:
[root@station20 ~]# sestatus SELinux status: disabled
On a System with SELinux in Permissive Mode, it will display:
[root@vbg ~]# sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file: targeted
The first line informs us that SELinux is enabled in this system. The second line is of great significance. It displays the mount point of the SELinux pseudo file system. This file system is quite like the proc and sys file systems, and contains runtime information about your SELinux mode and various other things.
You can change run time parameters of the SELinux system by directly writing to the files in this pseudo file system. As an
example, just issue this command as the root user:
example, just issue this command as the root user:
[root@vbg ~]# echo 1 > /selinux/enforce
You will see that the mode of SELinux has changed from Permissive to Enforcing.
To return back to Permissive Mode, you can run either of the commands:
[root@vbg ~]# echo 0 > /selinux/enforce
…or:
[root@vbg ~]# setenforce 0
The third line mentions the current SELinux mode, whereas the fourth line mentions the SELinux mode under which the
system booted. The fifth line mentions the version number of the policy (we will come to this later in this series) and finally, the sixth line mentions the Policy loaded from the configuration file (
system booted. The fifth line mentions the version number of the policy (we will come to this later in this series) and finally, the sixth line mentions the Policy loaded from the configuration file (
/etc/sysconfig/selinux) at boot time.Understanding various types of policies
By definition, an SELinux policy is a collection of rules for SELinux Mandatory Access Controls. Each one of us can make a policy to suit our needs much like we define firewall rules through
iptables. There can be no standard policy that can apply to all situations.
By default, there are two policies shipped along with Red Hat Enterprise Linux: Targeted and Strict.
The Targeted Policy is the first step in assisting system administrators to understand and implement SELinux. It only ‘targets’ certain network daemons such as the Apache Web server, FTP server, BIND DNS server and a few others, while leaving the vast majority of end-user applications largely untouched. It creates an ‘unconfined’ domain ‘confinement’
(interesting paradox, isn’t it?) and does not apply Access Control Restrictions to most applications in the unconfined domain.
(interesting paradox, isn’t it?) and does not apply Access Control Restrictions to most applications in the unconfined domain.
This allows sysadmins to concentrate on the really vulnerable network applications and services while not interfering with their daily tasks.
Once the nuts and bolts of SELinux are clear to administrators, they should move forward towards implementing the SELinux Strict Policy.
The Strict Policy, on the other hand, is a true restrictive Access Control Policy. Before implementing this policy, make sure you understand SELinux concepts and policies well.
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 Types: 1513 Attributes: 148 Booleans: 210 Cond. Expr.: 186 Auditallow: 28 Dontaudit: 5086 Type_trans: 1398 Type_change: 17 Constraints: 47 Validatetrans: 0 Policy Version & Type: v.21 (binary, MLS) Classes: 61 Permissions: 220 Users: 3 Roles: 6 Sensitivities: 1 Categories: 1024 Allow: 82518 Neverallow: 0 Role allow: 5 Role trans: 0 Type_member: 0 Range_trans: 23 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.
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.
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:
- Users (3 in number)
- Roles (6 in number)
- 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,v 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 identity 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 leave a comment 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 this 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 it 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
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.
0 comments
Post a Comment