Why do you hate productivity?
When standing up this blog, I chose CentOS 7 as the underlying OS to get some experience with systemd and other new tech in Red Hat’s latest release. With Red Hat, of course, comes the specter of SELinux. There’s an attitude among some Linux admins that SELinux is just a pain in the ass that prevents you from getting work done, and the “fix” is to disable it outright. I get it. It’s extremely confusing when something as simple as trying to access a file you appear to have read permissions on fails with a misleading error message. Or a service fails to start for no apparent reason.
But configured properly, SELinux can give you a real leg up when it comes to security. With a new exploit or high-profile corporate breach in the news every week these days, you don’t need to be a Level 10 UNIX Wizard to see the value in another layer of protection. For 2015, I’ve decided to suck it up, eat my veggies and learn to love (or at least deal with) SELinux.
Configuring SELinux for Varnish 4
I chose to install Varnish as a caching layer in front of Apache, for the day my little blog makes the front page of Reddit. It’s going to happen any minute now. Just watch. And naturally, since I was starting from scratch anyway, I installed the latest version (4.0.2 as of this post). Apparently Varnish 3.x is properly configured for SELinux out of the box, but that is not the case for the new hotness in Varnish 4. You can find some gory details in the Red Hat bug tracker, but basically a code change in Varnish 4 makes it require access to a few new system calls which have not been whitelisted in the CentOS 7 SELinux packages.
This issue shows itself when you attempt to start up Varnish, and it fails. Checking on why, you can see there’s a strange permissions problem. SELinux rears its
ugly delightful head.
# systemctl status varnish <snip> varnishd: Failed to set permissions on ./vcl.UdrgPE5O.so: Operation not permitted
You can use the
audit2allow tool to parse the SELinux logs in
/var/log/audit/ and not only tell you why something was blocked, but how to fix it. Here, we’ll use the
-M flag which generates a module file that you can then import into SELinux.
# grep varnishd /var/log/audit/audit.log | audit2allow -M varnishd2 # semodule -i varnishd2.pp # systemctl restart varnish # systemctl status varnish varnish.service - Varnish a high-perfomance HTTP accelerator Loaded: loaded (/usr/lib/systemd/system/varnish.service; enabled) Active: active (running) since Sun 2015-02-01 04:09:15 UTC; 100ms ago
That’s it! If everything went correctly, varnish should now be running. The first command finds all Varnish activities that were blocked, and feeds them to audit2allow with the -M flag. This generates a SELinux module named
varnishd2.pp which can be loaded to allow all of the calls that had previously been blocked. I’ve named it varnishd2 because there’s already a
varnishd module shipped with CentOS. However, it’s the old Varnish 3.x edition that doesn’t work with version 4.
Was that so bad? (Ok, it was kind of bad). But now that you know this pattern, you can work your way around a lot of SELinux issues quickly the next time they crop up. Hopefully sometime down the line the SELinux packages will be updated, making this step unnecessary for Varnish 4.