Sometimes, you'll run into a problem that you can't fix either by changing the type or by setting a Boolean. In times like these, you'll need to create a custom policy module, and you'll use the audit2allow utility to do that.

The following is a screenshot of a problem I had several years ago, when I was helping a client set up a Postfix mail server on CentOS 7:

So, for some strange reason that I never understood, SELinux wouldn't allow Dovecot, the Mail Delivery Agent (MDA) component of the mail server, to read its own dict file. There's no Boolean to change and there wasn't a type problem, so setroubleshoot suggested that I create a custom policy module. It's easy enough to do, but you do need to be aware that this won't work with sudo on your normal user account. This is one of those rare times when you'll just have to go to the root user command prompt, and you'll also need to be in the root user's home directory:

sudo su -

Before you do it, be sure to put SELinux into permissive mode and then do something to induce the SELinux error. This way, you'll be sure that one problem isn't masking others. 

When you run the command to create the new policy module, be sure to replace mypol with a custom policy name of your own choosing. In my case, I named the module dovecot_dict, and the command looked like the following:

grep dict /var/log/audit/audit.log | audit2allow -M dovecot_dict

What I'm doing here is using grep to search through the audit.log file for SELinux messages that contain the word dict. I then pipe the output of that into audit2allow and use the -M option to create a custom module with the name dovecot_dict.

After I created the new policy module, I inserted it into the SELinux policy like so:

semodule -i dovecot_dict.pp

There was a also a second problem that required another custom module, but I just repeated this procedure to produce another module of a different name. After I got all that done, I reloaded the SELinux policy, in order to get my new modules to take effect:

semodule -R

With semodule, the -R switch stands for reload, rather than recursive, as it does with most Linux commands.

With all that done, I put SELinux back into enforcing mode and exited back to my own user account. And I tested the setup to make sure that I had fixed the problem.

Of course, you also want to bear in mind that you don't want to just modify SELinux policy or contexts every time you see an sealert message in the log files. For example, consider this snippet from the messages file of my Oracle Linux 7 machine, which I set up mainly to run Docker and Docker containers:

Jun  8 19:32:17 docker-1 setroubleshoot: SELinux is preventing /usr/bin/docker from getattr access on the file /etc/exports. For complete SELinux messages. run sealert -l b267929a-d3ad-45d5-806e-907449fc2739
Jun  8 19:32:17 docker-1 python: SELinux is preventing /usr/bin/docker from getattr access on the file /etc/exports.#012#012*****  Plugin catchall (100. confidence) suggests   **************************#012#012If you believe that docker should be allowed getattr access on the exports file by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# grep docker /var/log/audit/audit.log | audit2allow -M mypol#012# semodule -i mypol.pp#012
Jun  8 19:32:17 docker-1 setroubleshoot: SELinux is preventing /usr/bin/docker from getattr access on the file /etc/shadow.rpmnew. For complete SELinux messages. run sealert -l
. . .

These messages were caused by an early version of Docker trying to access resources on the host machine. As you can see, Docker is trying to access some rather sensitive files, and SELinux is preventing Docker from doing so. With Docker, and without some sort of MAC, it can be a trivial matter for a normal, unprivileged user to escape from the Docker container and have root user privileges on the host system. Naturally, when you see these sorts of message, you don't want to automatically tell SELinux to allow the prohibited actions. It just may be that SELinux is preventing something truly bad from taking place.