NGINX SELinux Configuration

Importance of SELinux

SELinux is a 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 SELinux for other things to work. But this isn’t correct. You shouldn’t lessen your server security. You must configure SELinux properly instead!

The GetPageSpeed NGINX module packages (ModSecurity, PageSpeed) ship with extra -selinux subpackages which are automatically installed to ensure maximum SELinux compatibility.

It’s worth noting that the following bug is present in the base package from nginx.org. The fix is easy systemctl edit nginx and paste in:

ExecStartPre=/usr/bin/rm -f /run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t 

If you’re running NGINX that was installed from other repositories or a compiled install, you will likely run into many SELinux issues.

Let’s review basic configuration changes you need for SELinux to play nicely with any 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 the 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 the SELinux configuration.

Install SELinux troubleshooting tools

For audit2allow command:

yum install policycoreutils-python

For sealert command:

yum install setroubleshoot-server

Install documentation

It is useful to have documentation for SELinux policy:

yum install selinux-policy-doc 

Now you can read extensive documentation for HTTP daemon SELinux policy by running:

man httpd_selinux

Check SELinux violations using audit2allow

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 an SELinux policy for us.

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 using 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

Example 3. NGINX listen sockets

Your configuration may include listen directive defining location of UNIX socket files where it will listen for connections (as opposed to TCP port), e.g. /var/run/nginx/nginx.sock. In this case you need add those locations to proper security context:

semanage fcontext -a -t httpd_var_run_t "/var/run/nginx(/.*)?"  

Check SELinux violations using sealert

You may want to try sealert for extensive report of SELinux violations in general like this:

sealert -a /var/log/audit/audit.log

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 the 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 a 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 a web server, read man httpd_selinux.

ngx_pagespeed and SELinux

The 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

But even better, just use our package repository, which automatically installs the SELinux policy module file when you install the PageSpeed module.
Here are instructions for installing PageSpeed module in CentOS/RHEL 7 (and the same for CentOS/RHEL 8).

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!

The interested readers might also check some insight about minimal SELinux policy.