SElinux is a beautiful thing. I love it! However, the drawback of a very fine-grained security control is, that the policy needs to be exactly right. Almost right won't do it.
This bite me when I realized, that systemd couldn't control StrongSWAN's charon - IKE-daemon. It worked flawlessly, when running a simple strongswan start, but failing on systemctl start strongswan. Darn! When the thing works, but doesn't work as a daemon, to me it has the instant smell of SElinux permission being the culprit.
Very brief googling revealed, that other people were suffering from that same issue:
- Bug 1444607 - SELinux is preventing starter from execute_no_trans access on the file /usr/libexec/stro
ngswan/charon.
- Bug 1467940 - SELinux is preventing starter from 'execute_no_trans' accesses on the file /usr/libexec/strongswan/charon.
Others had made the same conclusion: it's a SElinux -policy failure. Older bug report was from April. That's a month before Fedora 26 was released! But neither bug report had a fix for it. I went to browse Bodhi and found out that there is a weekly release of selinux-policy .rpm-file, but this hadn't gotten the love it desperately needed from RedHat guys.
Quite often self-help is the best help, so I ran audit2allow -i /var/log/audit/audit.log and deduced a following addition to my local policy:
#============= ipsec_t ==============
allow ipsec_t ipsec_exec_t:file execute_no_trans;
allow ipsec_t var_run_t:sock_file { unlink write };
I have no idea if that fix is ever going to be picked up by RedHat, but it definitely works for me. Now my IPsec tunnels survive a reboot of my server.
Update 10th Sep 2017:
Package selinux-policy-3.13.1-260.8.fc26.noarch.rpm has following changelog entry:
2017-08-31 - Lukas Vrabec <lvrabec@redhat.com> - 3.13.1-260.8
- Allow ipsec_t can exec ipsec_exec_t
... which fixes the problem.
To test that, I dropped my own modifications out of local policy and tested. Yes, working perfectly! Thank you Fedora guys for this.
