I was recently setting up the normal IPSec/IKE daemon stack on a stock Fedora 22 machine in order to reproduce and get a clean kernel stack trace for a kernel panic involving IPSec (which is very relevant to me). I keep around such a stock Fedora install in a virtual machine because because it's useful to have a reference that hasn't been particularly mangled by me in order to make it usable; as part of that stock-ness, it has SELinux enabled.

As part of IPSec setup, I needed to set up a host key:

ipsec newhostkey --configdir /etc/ipsec.d --output /etc/ipsec.d/thismach.secrets

# print it out for the config file:
ipsec showhostkey --right

I set up an appropriate /etc/ipsec.d/testconn.conf, uncommented the bit in /etc/ipsec.conf to include things from /etc/ipsec.d (why this isn't standard I don't know), started up IPSec services with 'systemctl start ipsec', and SELinux promptly and cheerfully reported that it had blocked pluto's access to /etc/ipsec.d/thismach.secrets because the file did not have the magic type attribute of (I believe) ipsec_key_file_t.

Let me be plain here: this is robot logic. SELinux knew exactly what was going on; an IPSec daemon was trying to read keys from the place that IPSec keys are configured to be and are known to be. The key had even been created using official tools. But because the magic SELinux chicken had not been waved over the file, the request was denied and my IPSec connection failed to start. This is not usable, appropriate security; instead this is the kind of horseshit that causes sysadmins to chuck SELinux over the transom.

(Yes, there are high security environments where it's sensible to worry about 'maybe someone hardlinked /etc/shadow into /etc/ipsec.d and is now exfiltrating it through a pluto vulnerability'. Those environments are not typical and the default security setup should not be designed for them, not if you want people to actually use said (default) security setup.)

I don't have any particular opinions about exactly how SELinux should solve this, but it needs to. Robot logic is one of the deep failings of SELinux and people determinedly standing behind it is one of the big things that leads to SELinux's toxic mistake.

(As usual, the other piece of terrible SELinux usability is that I would have had no idea that things were blowing up due to SELinux if I hadn't been running a desktop on the Fedora 22 virtual machine so that SELinux could pop up an alert. You can imagine how enthused this makes me about ever deploying SELinux on servers.)