Debugging SELinux errors, and writing custom policies

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
Network Opensource Openstack

Neutron security_group_rules_for_devices RPC rewrite

During scalability tests with openstack/neutron we found that the

During scalability tests with openstack/neutron we found that the security_group_rules_for_devices RPC, which is transmitted from neutron-server to the neutron L2 agents during port changes, grew exponentially.

We filled a spec for juno-3, the effort leaded by shihanzhang and me can be tracked here:

I have written a test and a little -dirty- benchmark ( line 418) to check the results and make sure the new RPC actually performs better.

Here are the results:

Message size (Y) vs. number of ports (X) graph:

RPC execution time in seconds (Y) vs. number of ports (X):

Opensource Projects

KiCad Win32 full scripting support

Brian Sidebotham and and Dick Hollenbeck just did it!,

Long story short: A few months ago we suffered as soon as we discovered that the standard python binaries for win32 were MSVC built, and they had runtime discrepancies with some modules or executables built from mingw (wxpython support), that always ended execution with a segmentation fault.

At that time I was getting “a little” busy, but dick & brian kept working. They discovered that python has no support to build outside MSVC on windows(really, it doesn’t), so dick started python-a-mingw-us project, which cmake-compiles python 2.7.4 and builds a set of win32 binary installers or python 2.7.4, fully mingw runtime compatible. After that, Brian kept working on his kicad winbuilder, yesterday he announced that he got it working in full : wxpython, scripting, everything.