[HOWTO] - Configure, and Tune SELinux and Contexts

If you figure out how to do something interesting/cool in Cacti and want to share it with the community, please post your experience here.

Moderators: Moderators, Developers

Post Reply
Cacti User
Posts: 92
Joined: Mon Apr 09, 2018 1:37 pm

[HOWTO] - Configure, and Tune SELinux and Contexts

#1 Post by mmccaugh » Mon Nov 26, 2018 1:22 pm

All of this was completed on a Centos 7.3 Server, these instructions should work on any Redhat Arch system, but file locations and command structures may vary slightly on Debian and other builds.

**All commands here are executed with elevated privileges, some MAY work without elevation but this document assumes you have root privileges and understand basic Unix/Linux permissions**

SELinux is the culprit in MANY instances where something isn't working for no apparent reason.. And many times the approach is to simply disable it (Losing any protection it affords) rather than properly tune it. This is intended to be a short guide on how to identify and properly resolve issues SELinux is causing.

1. Determine if SELinux is running with the command 'sestatus'
[[email protected]]# sestatus
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Max kernel policy version: 28
The relevant information from this output is :
SELinux status: enabled
Selinux is Running. (If this doesn't say running then SELinux isn't your problem)
Loaded policy name: targeted
Selinux is running the "Targeted" policy, options here are "targeted, minimal, and mls" with targeted being the most commonly used.
Current mode: permissive
Selinux is running in "permissive" mode, which means passive (It will log but not block anything) (If this says Permissive, or Disabled then SELinux is not your issue, in permissive mode the daemon will LOG but it will not actively block or deny anything)

The logfile for SELinux is /var/log/audit/audit.log and this is where all activity logged by SELinux, and activity taken is stored. This logfile however is NOT easy to read, luckily however there is a great utility to help named audit2allow

In the case of an issue the command to use (it is highly recommended you read the audit2allow MAN page as there are many options) is 'audit2allow -a -w -l'

The -a flag tells audit2allow to read in the audit and messages logs.
The -l flag tells audit2allow to only read messages since last policy reload (So if you FIX issues, you will not see old denies you have since fixed)
The -w flag tells audit2allow to tell you 'why' a deny happened.

This command parses the log files, and then gives you a plain English interpretation of denies AND the command needed to tell SELinux to ALLOW the access instead (If it should be allowed)

**NOTE** DO NOT just permit everything you see here, you will need to read what is displayed and determine if access is related to Cacti or not, but under no circumstances should you just roll through the displayed report and allow everything you see as SELinux is SUPPOSED to block some stuff..
type=AVC msg=audit(1542755131.314:25368): avc: denied { open } for pid=23309 comm="httpd" path="/var/www/html/cacti-1.1.36/include/cacti_version" dev="dm-2" ino=1704998 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
Was caused by:
The boolean httpd_read_user_content was set incorrectly.
Allow httpd to read user content

Allow access by executing:
# setsebool -P httpd_read_user_content 1
This is an example of a deny in SELinux.

Relevant Info from this -

1. The httpd process was denied access.
2. /var/www/html/cacti-1.1.36/include/cacti_version was the file
3. setsebool -P httpd_read_user_content 1 is the command we would use to tell SELinux to allow the access.

Now SELinux is one part of this process, another is something called "File Contexts" and is part of how SELinux classifies files and directories.

To see the context of a file or directory simply add the -Z flag to the ls command
[[email protected] mike]# ls -alZ
-rw-r--r--. mike users unconfined_u:object_r:user_home_t:s0 logo.txt
In your home directory most files will look like this..
-r--r-----. root root system_u:object_r:etc_t:s0 sudoers
drwx------. root root system_u:object_r:virt_etc_t:s0 libvirt
Looking at a few files in /etc however you will see a bit of how files and directories are classified using these contexts..
drwxrwxr-x. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 cacti-1.1.36
This is an example of how your Cacti tree should look.. Lets assume it doesn't however, and we want to fix it rather than permit the WRONG contexts through SELinux..
This is what the deny shows from audit2allow though.. Note the Context is NOT what it should be.. Instead it looks like what the context was in the user home directory.. Almost like the directory was improperly uncompressed int he user home directory and moved without retaining the proper security contexts because someone was careless... :roll:

In this case the proper action isn't to allow the access but to fix the contexts which we will cover below..

The 'restorecon' command is used to restore contexts to what their defaults should be..

Assuming this directory were wrong the command we would run (Again READ THE MAN PAGE.. There is a Lot more to this command than this basic overview)

restorecon -R -n -v cacti-1.1.36

The -R flag here operates the same as in a lot of other cases, it specifies recursion (We want to fix the entire tree not just the head directory)
The -v flag again just like many other commands specifies verbosity (And like other commands multiple levels can be specified with more "-v's"
The -n flag here says "Do Nothing" it will tell you what WOULD be changed, but won't actually modify anything. ALWAYS do this first, verify it is going to do what you expect (And need it to) and then run the command again without the -n flag

There is a LOT more to managing SELinux than is listed here, but this should be a good primer and if this guide deters even a few people from simply disabling the protection SELinux offers rather than properly configure it then that is a great thing!

A great approach to SELinux is to build a server, and place the daemon in 'permissive' mode, because in permissive mode it will do NOTHING, it will block NOTHING, and it will break NOTHING, but it will LOG EVERYTHING 'as if' it were blocking, so your logs will LOOK exactly like they would if the daemon were running in enforcing mode.. Which means you can let it run for a few days while you tune your system, use the audit2allow command to list what it 'would' be blocking, and fix it either by fixing file contexts where applicable or by correcting your SELinux policy as shown above. Once you are confident the server is properly tuned you then set SELinux to enforcing and instantly elevate yourself in the eyes of your Linux peers!

Post Reply