== SELinux's usability, illustrated once again

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
https://bugzilla.redhat.com/show_bug.cgi?id=1272571]] (which is
[[very relevant to me IKEForPointToPointGRE]]). 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.

.pn prewrap on

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 SELinuxToxicMistake]].

(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.)