Month: October 2014

Sometimes you find yourself trying to debug a problem with SELinux, specially during software development or while packaging new software features.

I have found this with neutron agents to happen quite often, as new system interactions are developed. Disabling selinux during development is generally a bad idea, because you’ll discover such problems later in time and under higher pressure (release deadlines).

Here I show a recipe, from Kashyap Chamarthy, to find out what rules are missing, and generate a possible SELinux policy:

Make sure selinux is enabled

sudo su -
setenforce 1

Clear your audit log, and supposing the problem was in neutron-dhcp-agent, restart it.

 > /var/log/audit/audit.log
systemctl restart neutron-dhcp-agent

Wait for the problem to be reproduced..

Find what you got, and create a reference policy

cat /var/log/audit/audit.log
cat /var/log/audit/audit.log | audit2allow -R

At that point, report a bug so you get those policies incorporated in advance. Give a good description of what’s blocked by the policies, and why does it need to be unblocked. Now you can generate a policy, and install it locally:

You can generate a SELinux loadable module to move on without disabling the whole SELinux:

cat /var/log/audit/audit.log | audit2allow -a -M neutron

And you can also install it in runtime

semodule -i neutron.pp

Restart neutron-dhcp-agent (or re-trigger the problem to make sure it’s fixed)

systemctl restart neutron-dhcp-agent