Ooops! I did it again. I threw SELinux in the trashcan.

So, once again, I crashed head on into  SELinux's "user experience". And, once again, it sucked.

I keep SELinux enabled on my workstation in order to be, now and then, reminded of its existence and to see if it becomes by any chance usable, as I disable it on all production machines.

Yesterday,  I needed to test a milter that I am modifying for sendmail, and I needed to do it on my machine. It was a thoroughly joyless experience.(Note: I have been doing this kind of stuff for the last twenty years or so. Some would say I should know better by now).

As soon as I fired up the daemon and hooked it to sendmail, sendmail began spewing "Permission denied" messages all over the log file, complaining about being denied access to the socket that it should have used to communicate with the milter.

I entered Google frenzy, and after a while I began homing in on a SELinux problem.

I used yum to install a couple of other milter packages (which worked fine), and ran 'ls -Z' on the corresponding files to check their context (under SELinux, you can forget to get the whole permission story with ls -l. Ain't that nice.) I then used chcon on the files of my milter and  made the context identical to the ones of the working milters, as advised as a workaround by a smattering of bug reports peppering the net. Guess what? Didn't work. I eventually ran into a situation where SELinux was not allowing me to chcon the involved files anymore. This means that you (as root) are not allowed to change the permissions/context of a file (which you may well have created and own)  because of the context it has (context which you may well have set on it). What one has to do in that situation, beats me - I also no longer care, as it will be clearer later.

But wait! Why did I have to google my problem in the first place? Surely SELinux provides plenty of logging help to its hapless victims. NOT. (And if you believed that, would you be interested in some Florida real estate?)

SELinux writes bubke to log files, any log file. And the permission errors it causes are indistinguishable from the regular garden variety. What would signal that something is wrong with SELinux is a separate daemon, called auditd, which is endowed with the following properties:

1. It requires you to be aware of its existence. SELinux is very happy to run stealthily without it. 
2. Of course, auditd won't write in a mundane place like /var/log/messages. It writes in its own private log, which - in my distro, Fedora 18 - is also whisked away under /var/log/audit/. God forbid that you 'grep' it by mistake and be overwhelmed by information.  
3. It has to be running. Which it would be, by default, except the latest upgrade somehow disabled it (sheesh).
4. It runs an advice wizard that sort of tells you how to get a fix. Which is nice, but it requires you to be logged into a graphical shell (AND to be running the appropriate applet). So it is less than ideal if you plan to deploy SELinux on a server, but hey, that is a loony idea in itself, right?

I turned the auditd machinery on,ran the applet, noted its advice, applied it. So after four hours of  "development" I found myself  as good as when I started. All I had achieved to this point was changing this message: 

Milter (smf-sav): open /var/run/smfs/smf-sav.sock failed: Permission denied

into this pair of messages:

NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1693: Xsmf-sav: local socket name /var/run/smfs/smf-sav.sock unsafe: Permission denied

/etc/mail/sendmail.cf: line 1693: Xsmf-sav: local socket name /var/run/smfs/smf-sav.sock unsafe: Permission denied

What fun.

So, in order to preserve my sanity, I set SELINUX=disabled in /etc/sysconfig/selinux and reebooted.  When the machine rebooted, I was staring at the same messages as above. However, while I was looking for a suitable sledgehammer to take to the monitor, I  suddenly remembered that "local socket name is unsafe" is a profoundly brain damaged  diagnostic that sendmail issues in several circumstances. For instance, the message is issued when the file does not exist. I started the milter, it created the file and I was sort of back in business (I actually went home).

So, what had (probably) happened, was that the fix suggested by auditd had worked, but by that time the milter had for wahtever reason gone awy and the relevant files had been removed (I may be to blame on both counts, God knows I wasn't completely lucid at that point).

So once again SELinux is off my workstation, and I don't seeit coming back any time soon.

I am sure that SELinux apologists will point out several flaws in my behaviour and conclude it's all my fault.

Off the top of my head:

1. I was dabbling with things of which I have limited and insufficient understanding
2. I was'nt running auditd
3. I am running sendmail 
4. Had I  been more systematic, the fix would have worked.

To which I will reply that: 

1. True enough. But (remember?) my main task was mail related. I can use the standard Unix permission system without qualified knowledge of most of the innards of the kernel. The closest I would get to gain a similar insight in SELinux is by digesting a couple of ponderous tomes, then get extremely well acquainted with how SELinux   is used in my distribution, because the way it actually works is embedded in the security policy (as opposed to simply depending on ownership and permissions of the source and target files). To which my reaction is "Come again?"
2. I surely did not turn off auditd; a quirk of the distro upgrade did. But even if I had been inclined to turn auditd off, if it is such a critical piece of armory when running SELinux, then it should be a requirement - which it is not.
3. This is not the place for me to defend sendmail. Suffice it to say that milters are used also by qmail  and postfix in much the same way, so 99.9% I would have run into the same walls with other MTAs. Also, braindead diagnostics are by  no means a sendmail exclusive.
4. That's true. Maybe it would have worked. Maybe not. To find out I'd have to reactivate SELinux, relabel the file system and then check. Guess what? I'm not doing it.

But even if it did work, consider this. At the beginning of the story, I did not set out to become a SELinux expert. I just needed to make a system daemon able to read a file. All of a sudden, I had to try to make sense of security contexts, system_u:var_run_t, ls -Z and god knows what else.

Besides, the suggested 'fix':

# grep sendmail /var/log/audit.log | audit2allow -M mypol

# semodule -i mypol.pp

which might have worked, is far from perfect. It needs a wizard to figure out, it's highly cryptic, it performs its magic through binary files which disappear in SELinux's guts, and gives me no obvious way to find out that it has been applied. So now I have borked my machine's security policy in a way I will not be ever able to replicate by other means; as a boon I have no way to ascertain that the fix is there, should I forget about it, unless I turn myself into a SELinux specialist. Also, the only useful  insight I have gained in the process is "Turn off SELinux if you value your time". Tell me about "Learn by doing"

All this is a madness on par with the Windows permission system, but without the GUIs  - 'nuff said.

TL;DR: After  more than 10 years, SELInux is still a giant stinking, fuming pile of crap. Avoid like the plague.