Created Thu Jun, 20 2019 at 05:03PM
If you are unsure it's SELinux, first try temporarily disabling SELinux enforcing
sudo setenforce 0 see Ref. and run the code that was failing. If it is SELinux read on..
I ran into this issue recently and was pretty unfamiliar with SELinux so it was a bit of a learning curve for me. Unlike DAC the standard posix mode permissions you're used to using to set ownership and file read,write,execute permissions, SELinux is a lot more granular with it's permissions. It will in certain cases deny specific operations such as connecting to the internet over TCP/443, allow writing to /foo & /bar, but nowhere else etc. depending on the caller (application). I liken this to MS Active Directory group policies.
To view a files (MAC) mandatory access control permissions
ls -Z or users
id -Z with output in the
In my case on Centos7 I had a script called in a logrotate.d conf file with a prerotate script that would upload a logfile before it was rotated. I was having several denials (logged to
/var/log/audit/audit.log). I learned you can use a few tools to generate specific policy package to install. I am creating .rpm packages for our code, so I added all the steps below to the .spec file to generate & install a policy package during time of install.
What you'll need: policycoreutils-python, checkpolicy (might already be installed)
From what I understand if you plan on distributing this security policy the idea is you want to only ship the *.te file and generate the policy onsite so if the definitions that policy relies on get updated, they will be inherited at time of install.
watch "tail /var/log/audit/audit.log | grep 'denied'"
grep 1561055176.928:11371 /var/log/audit/audit.log|audit2allow -m myapp > myapp.te
cat /var/log/audit/audit.log | grep logrotate | audit2allow -m myapp > myapp.te
cat /var/log/audit/audit.log | grep logrotate | audit2why
WARNING During this step I found audit2why reporting my script would work if I ran
setsebool -P nis_enabled 1. While that sounds fine and dandy you should always lookup what the security implications are of running those commands. Setting this may broaden your attack surface, so user beware.
checkmodule -M -m -o myapp.mod myapp.te
semodule_package -o myapp.pp -m myapp.mod
semodule -i myapp.pp
I had to do these steps several times until I had accumulated all the tiny permissions my code needed to operate.