Let’s start by stating I’m by no means an SELinux expert, but after the CentOS 7.4 upgrade hurdle I sure am more informed than I was with 7.3. So SELinux is a security mechanism that has a bunch of policies to allow stuff to happen. Anything not included in those policies will be blocked from happening.

The first thing you wanna do is:

yum install policycoreutils-python setools-console

The single most important log file you need to check is /var/log/audit/audit.log. You can also check these events with the aureport tool if you wish. If you want to find any recent denied events, you might do so with a grep:

grep denied /var/log/audit/audit.log

Or if you wanna see it live:

tail -f /var/log/audit/audit.log | grep denied

To see if SELinux is enabled at all (it is, unless you or someone else explicitly turned it off):

sestatus

From what I understand, processes run under a certain source context and what they want to access is in a certain target context.

To query the list of available types which contexts can have:

seinfo -t | sort

To check the context of processes:

ps auxZ

Similarly, to see the context of the contents of a directory:

ls -alZ

For the list of installed SELinux modules:

semodule -l

You can change the context of a directory:

semanage fcontext -a -t var_lib_t /web
restorecon -v /web

First semanage sets up the context, then you need restorecon to perform the actual relabeling. Note that this only changes the context of the directory itself, but nothing inside it. To do the same recursively:

semanage fcontext -a -t var_lib_t "/web(/.*)?"
restorecon -rv /web

To remove a context entry and apply the change:

semanage fcontext -d "/web"
restorecon -v /web

Let’s see an example denied event from the audit log:

type=AVC msg=audit(1505388256.060:145109): avc:  denied  { name_connect } for  pid=5674 comm="java" dest=43 scontext=system_u:system_r:tomcat_t:s0 tcontext=system_u:object_r:whois_port_t:s0 tclass=tcp_socket

If you want to allow this specific action, put this in foobar.log (where foobar is the desired name of the policy module), then you can:

audit2allow -i foobar.log -M foobar
semodule -i foobar.pp

In case you’re crazy enough to write your own policy modules (.te files), you can deploy them with a script like this, let’s call it sedeploy.sh:

#!/bin/sh

set -e

MODULE=${1}

# this will create a .mod file
checkmodule -M -m -o ${MODULE}.mod ${MODULE}.te

# this will create a compiled semodule
semodule_package -m ${MODULE}.mod -o ${MODULE}.pp

# this will install the module
semodule -i ${MODULE}.pp

Where the module name will be the first parameter of the script.

Welp, that’s it for now. Stayed tuned, because next time I’ll provide some specifics regarding SELinux + Tomcat on EL 7.4.

Credits: thanks a lot for the folks of #centos for their help!