2015-11-04
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 (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.)
Outlook.com now has collected some SBL listings
I mentioned on Twitter that portions of outlook.com are now on the SBL. At the moment there are two listings for protection.outlook.com hosts; SBL272953 from October 11th and SBL273948 from October 21st. Both spam samples quotes by Spamhaus show the signs of a null sender, so clearly these people are as entrenched as I thought. Microsoft also has a Hotmail SBL listing, SBL268930, from September 10th.
(All Microsoft SBL listings can be found here, which is a link I want to keep for my own reference if nothing else.)
Clearly Microsoft doesn't care enough about these SBL listings to do anything about them. It's not clear why this is so, though. Perhaps the Microsoft abuse system is undermanned and overwhelmed. Perhaps a SBL listing doesn't affect delivery to enough places for Microsoft to care (especially a SBL listing for just one or two IPs out of the many that protection.outlook.com hosts use). Perhaps Microsoft simply hasn't noticed the SBL listings.
Locally we've seen connections from one of these IPs in the past week, and all of the deliveries were for null sender address so they were almost certainly spam. This means that I don't currently have to worry about the effects on our users of outlook.com getting more widely listed in the SBL (which is a concern, since some of the university's own email comes from there).
(Only some users subscribe to SBL-based rejection, but in the past SBL listings have clearly been a significant input to the spam score our commercial anti-spam system computes for messages. My unscientific belief is that a great many people filter their email based on that score, so widespread SBL listings for outlook.com could well push the scores for outlook.com email into 'filter away' territory. If this happened, there would be basically nothing we could do about it.)