What is SELinux? How to Allow Non-Compliance with the Default Security Policy?
SELinux (Security-Enhanced Linux) is a project that enables the realization of mandatory access control (MAC) mechanism in Linux.
DAC and MAC
Under On-demand access control (DAC), whether a user or process can access files, sockets, and other resources is determined by looking at user ownership or permissions.
Mandatory access control (MAC) is a security mechanism that restricts the users’ audit level over objects they created. In the optional access control, when users have full control over their files, directories, etc., the mandatory access control adds additional labels or categories to all file system objects. Users and processes must have appropriate access rights to these categories to access them.
All the access decisions in optional access control are based on the user’s identity and ownership. It means, by exploiting the vulnerability, a malicious application can use all resources the user has access to. With SELinux, you can differentiate users and user rights. For example, you can allow users to log on to the system via a shell or GUI to do what they want in their home directory. On the other hand, you can restrict an application that the user runs from accessing some files or directories in this home directory.
How does SELinux work?
When a subject (such as an application) tries to access an object (such as a file), the policy application server in the kernel primarily controls the access vector cache for the subject and object permissions. If it cannot decide by looking at the cache, the server determines whether it performs access according to security policies. It is also useful to say that SELinux does not crush access rules set in DAC.
SELinux Modes
SELinux has three modes. These are;
- enforcing: The access to resources is determined according to the SELinux policy.
- permissive: The SELinux policy is not enforced in this mode. However, cases that do not comply with the access policy are written to a log file. (In Redhat, it writes to /var/log/audit/audit.log by default)
- disabled: SELinux is entirely disabled. Only DAC rules apply.
You can configure the SELinux using the /etc/selinux/config file.
# This file controls the state of SELinux on the system. SELINUX=enforcing SELINUXTYPE=targeted
With the SELINUX option, we determine the working mode of SELinux. With SELINUXTYPE, we define which SELinux policy is applied. These are;
- stricted: Access policy handles all processes in the system.
- targeted: Access policy only works for targeted processes (such as dhcpd, httpd, named, nscd, ntpd).
- mls: Multi-level security protection
The getenforce and sestatus commands can be used to identify SELinux’s mode.
$getenforce Enforcing $sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: disabled Policy version: 24 Policy from config file: targeted
The biggest reason for writing this article was that SELinux in Redhat came in enforced mode by default, and I was unaware of it. I received “permission denied” alerts when I used a port not defined in the SELinux policy for a daemon on the server or when I tried to send email using the web server’s mail server. In such cases, we may see the access requests that do not comply with the policy by looking at the /var/log/audit/audit.log file.
A sample line from the audit.log file:
type=AVC msg=audit(1375367543.933:109729): avc: denied { name_connect } for pid=2591 comm=”httpd” dest=25 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:smtp_port_t:s0 tclass=tcp_socket
This line tells us that the httpd process, with pid: 2591, is trying to connect to port 25 but access is denied. We can get the output to be more readable by adding the -w (why) parameter to the audit2allow command:
#audit2allow -a -w Was caused by: Unknown - would be allowed by active policy Possible mismatch between this policy and the one under which the audit message was generated. Possible mismatch between current in-memory boolean settings vs. permanent ones. #audit2allow -a #============= httpd_t ============== allow httpd_t home_root_t:file getattr; #!!!! This avc can be allowed using one of the these booleans: # httpd_can_sendmail, allow_ypbind, httpd_can_network_connect allow httpd_t smtp_port_t:tcp_socket name_connect;
As a result of this command, we can see the rules to allow rejected access in audit.log.
#audit2allow -a -M httpd_module
Within that command, the name httpd_module.pp consists of a policy package that compiles the type enforcement rules, and two files named httpd_module.te that type enforcement rules write.
We use the following command to load the module:
#semodule -i httpd_module.pp