Importance of SELinux

SELinux is Linux security system based on role access. It comes enabled by default in recent RedHat and CentOS versions. Quite many sources online will tell you to disable <abbr class="nocode" title="" data-original-title="Security-Enhanced Linux" style="box-sizing: border-box; border-bottom: 1px dotted rgb(119, 119, 119); cursor: help; text-decoration: none;">SELinux</abbr> for other things to work. But this isn’t correct. You shouldn’t lessen your server security. You must configure SELinux properly instead!

Let’s review basic configuration changes you need for SELinux to play nicely with servers running nginx.

Enable SELinux

First of all, let’s make sure that SELinux is running in enforcing mode globally.

setenforce 1

Default SELinux policy labels nginx and its associated files and ports with domain (type) httpd_t.
So what we are going to do next is allow nginx to run in permissive mode.
In this mode nginx (and php-fpm) will run without restrictions, but, Linux will log all SELinux related errors. Run:

semanage permissive -a httpd_t

Ok, great. Now our system is enforcing SELinux policy while still allowing all activity for nginx and php-fpm. We can now use log entries to adjust SELinux configuration.

Install complementary tools

yum install selinux-policy-doc # will install documentation for policy

Check SELinux violations

grep nginx /var/log/audit/audit.log | audit2allow -m nginx

If you don’t have any policy violations by nginx, the command will output:

You must specify the -p option with the path to the policy file.

Otherwise it will build up a SELinux policy for us.

We we will not use the generated policy directly. Instead, it will help us to identify the nginx configuration errors or adjust the SELinux configuration via boolean flags (most common case).

Example 1. Bad location for nginx fastcgi cache

Example output:

module nginx 1.0;

require {
    type httpd_t;
    type httpd_config_t;
    class dir { add_name remove_name write };
}

#============= httpd_t ==============
allow httpd_t httpd_config_t:dir { add_name remove_name write };

How to really interpret this? It appears that nginx tries to change contents of httpd_config_t. Let’s see what it is:

semanage fcontext -l | grep httpd_config_t

You will see that the output includes location /etc/nginx(/.*)?. So in most probability nginx is trying to change contents within its own configuration (/etc/nginx).

This is commonly caused by storing fastcgi cache within that directory. In our case, the misconfiguration is with the following nginx configuration line for micro-fastcgi cache:

fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=microcache:10m max_size=256m inactive=30m;

Let’s find a more appropriate place for storing it, which might be already allowed by default SELinux policy. To see all locations associated with nginx, run:

semanage fcontext -l | grep nginx

In the output we see /var/lib/nginx(/.*)? location present with context system_u:object_r:httpd_var_lib_t:s0. That sounds like a better location for our microcache. But it is not present! Let’s create the location and make sure to re-label it (apply SELinux contexts):

mkdir -p /var/lib/nginx/microcache
chown -R nginx /var/lib/nginx
restorecon -Rv /var/lib/nginx

Now adjust nginx configuration to point to the new location which satisfies current SELinux policy better:

fastcgi_cache_path /var/lib/nginx/microcache levels=1:2 keys_zone=microcache:10m max_size=256m inactive=30m;

Let’s verify that our microcache directory SELinux label matches to the one in policy:

matchpathcon -V /var/lib/nginx/microcache

Should output “/var/lib/nginx/microcache verified.“.

Example 2. worker_rlimit_nofile and SELinux

If you’re using this nginx configuration directive, e.g. worker_rlimit_nofile some-number; then the following would likely be included into generated SELinux policy:

module nginx 1.0;

require {
    type httpd_t;
    class process setrlimit;
}

#============= httpd_t ==============

#!!!! This avc can be allowed using the boolean 'httpd_setrlimit'
allow httpd_t self:process setrlimit;

Look at the 2 last lines. They tell you that nginx is trying to issue setrlimit system call. It suggests to use a boolean flag to easily enable this activity. This is all we need to allow that activity in enforcing mode:

setsebool -P httpd_setrlimit on

SELinux and PHP-FPM

Check for PHP-FPM errors like so:

grep -R php-fpm /var/log/audit/audit.log

You might see errors of the following type:

type=SYSCALL msg=audit(1502113625.315:36455): arch=c000003e syscall=21 success=yes exit=0 a0=7f125afedcc8 a1=2 a2=0 
a3=7ffe5a8c3a00 items=0 ppid=9855 pid=13146 auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 
sgid=1001 fsgid=1001 tty=(none) ses=4294967295 comm="php-fpm" exe="/usr/sbin/php-fpm" subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(1502113640.696:36458): avc:  denied  { write } for  pid=13190 comm="php-fpm" name="autoptimize" dev="sda" ino=262322 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=dir

If PHP-FPM is being used with nginx and cannot write to web directories when httpd_t is in enforcing mode, then you should relabel the directories that need to be written with proper type (httpd_sys_rw_content_t).

For WordPress, the default SELinux policy includes (among others) this location:

 /var/www/html(/.*)?/wp-content(/.*)?               all files          system_u:object_r:httpd_sys_rw_content_t:s0

So if we store our sites with different structure (outside html directory, for example), then we would need to add our locations permanently like so:

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/vhosts/(.*)/httpdocs/wp-content(/.*)?"
restorecon -Rv /var/www/vhosts/*/httpdocs/wp-content

These commands are much better alternative (and more correct) to setting httpd_unified boolean flag.

You might see similar errors logged related to locations. Most of the time the better solution would involve adding more locations to SELinux types (same as we did above). For the list of all file types relevant for web server, read man httpd_selinux.

ngx_pagespeed and SELinux

ngx_pagespeed module needs to execute things in memory (scheduler?). Which is why nginx would fail to startup should SELinux be in enforcing mode. This is the typical error you can find in nginx error log:

nginx[10624]: nginx: [emerg] dlopen() “/etc/nginx/modules/ngx_pagespeed.so” failed (/etc/nginx/modules/ngx_pagespeed.so: cannot enable executable stack as shared object requires: Permission denied) in /etc/nginx/nginx.conf:13

You can fix that with a one line command:

setsebool -P httpd_execmem on

Run Secure!

Now our nginx installation is ready to run in enforcing mode:

semanage permissive -d httpd_t

Thank you for reading and keep safe!