Products Solutions Contact TR

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.




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 which 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 access decisions in optional access control are based on the user’s identity and ownership. This means, by exploiting the vulnerability, a malicious application can use all resources the user has access. With SELinux, you can differentiate users and user rights. For example; you can allow a user logged on to the system via a shell or GUI to do what they want in their home directory; while restricting an application that user is running, 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 or not it will perform 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 3 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.

With SELINUX option, we determine the working mode of SELinux. With SELINUXTYPE, we define which SELinux policy will be 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.

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 me to write this article was that SELinux in Redhat came in enforced mode by default and I was unaware of it. I was receiving “permission denied” alerts when I used a port that was 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
%d bloggers like this: