Notes on persisting SELinux changes

Some notes on SELinux, and in particular persistence of changes over reboots.

Some of the anecdotal issues mentioned occurred a couple of years ago and may be resolved now, however in my mind it is not unreasonable to assume they are still current - you won't lose anything apart from a little time by assuming they are still current.

Identifying context

ls, ps netstat have a -Z option. tar supports SELinux however -Z was the compress flag in tar, before SELinux was a twinkle in some anonymous NSA nerd's eye, so the -Z option on tar won't get you SELinux info. --selinux and --noselinux are the relevant tar options. This will show SELinux info, such as SELinux user and file contexts. Obviously as always, man is your friend.

Don't trust the logs

SELinux logs to the audit.log file which is usually found at /var/log/audit/audit.log on a RHEL based host. When it logs.
In the past we've seen issues where an app would not work as desired but no SELinux event was logged. However turning SELinux off resolved the issue.
Conclusion? At that point in time not all SELinux events were logged. I'm not sure if this is still the case but if I have a problem that I can't identify and SELinux is enforcing, then I'll turn it off just to make sure.

Permissive mode can break things

Another blast from the past. Under RHEL5 running SELinux in permissive (i.e. log violations but don't enforce them) has been cited as a possible cause of issues for very time sensitive operations. In particular Oracle have advised that merely running SELinux in permissive mode can introduce enough additional latency to cause issues with active/active clusters. Again I am not sure if this is still the case, but it makes sense. If SELinux is permissive or enforcing every system call made is checked against the current state of the SELinux context and that will take some time and it's possible that extra time will introduce some additional latency and consume some number of instructions and possibly cause context changes and maybe pipeline purges.

Persistance

The default's in the current SELinux policy are applied on boot/reboot. This is sometimes referred to as "relabelling".

Temporary changes (e.g. chcon, setsebool) are lost on reboot as the policy is re-applied.

To edit the policy and therefore persist changes you need to use semanage. 

Notes and examples below.

getsebool -a|grep http   # list all booleans current state - handy to see if you can see something that looks appropriate to what you are doing.

#this changes the current state of the boolean but I don't think will persist across a reboot ie. is useful for testing and trouble shooting.

sesetbool httpd_can_network_connect_db=1

semanage allows you to manipulate the current SE Linux policy - therefore changes made with semanage  will persist across reboot.

semanage boolean -l

# will also list all booleans  current state  as does getsebool, however semanage boolean will also list the booleans default state as defined in the policy (i.e. what they will be set to on reboot)  and a description of their function.

e.g.:

semanage boolean -l:| grep httpd_can_network_connect

httpd_can_network_connect      (on   ,  off)  Allow HTTPD scripts and modules to connect to the network using TCP.

The "on" is the current state, the "off" is the policy's current default so the httpd_can_network_connect booelan would revert on reboot).

semanage boolean --on httpd_can_network_connect

Sets current state AND the policy's default - this should persist over reboots.

#check the policy default has changed

semanage boolean -l |grep httpd_can_network_connect

httpd_can_network_connect      (on   ,   on)  Allow HTTPD scripts and modules to connect to the network using TCP.

Now the SELinux policy's  default as well as the current state is changed to on. I believe this will persist accross boots.

You get the same behavior with chcon the command for changing file contexts .

I.e. changes made with chcon will not persist as they only occur on the filesystem which is "re-labelled" on boot to the defaults in the policy

So if you change a file context with chcon that change probably won't persists across reboots.

The file will be "re-labelled" when the SELinux policy as applied at boot.

chcon is handy for investigation and one off temporary fixes though.

You need to use semange fcontext to alter file contexts in the policy.

Pretty much audit2allow, semodule (which used to be how you loaded the generated module from audit2allow) and setting file contexts (chcon) and booleans (setsebool) are all the SELinux I've ever had to do to get stuff running with SELinux. I've either got it running with those three constructs or given up and used the ultimate SELinux fixer upper tool - banish ye SELinux. setenforce 0 !!