L'uso di questo sito
autorizza anche l'uso dei cookie
necessari al suo funzionamento.
(Altre informazioni)

Friday, October 18, 2013

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.

Monday, October 7, 2013

Back to the ole tty

Perhaps to certify my incipient old fart status, I have set myself to the task of not needing a gui mail client anymore. So I strung together mutt, my old mainstay emacs, threw in the very good Google book script, spruced it up with the (dark) solarized color theme, added some mailcap bits to keep in check those pesky html messages, and churned it with the help of a ton google searches.

Now, I can read a message write the answer and send it email by using a total of two mouse clicks. I could do it with zero mouse clicks, if I had really gone teletype and occupied my entire workspace with a big, honkin' terminal window (I don't), or if I mastered the ever-shifting keystrokes that my current window manager uses to switch windows (I won't). Also I could (acrobatically) be running mutt within emacs (with term.el). I am afraid to go down that path, though, lest I meet madness there.

As things are, I am reading mail in a mutt terminal window in my left monitor, and write it in an emacs frame in my left monitor - so i need to move the mouse from one to the other (and click the frames - uhm, perhaps I'll go back to implicit focus, how's that for the good old times?).

Thunderbird keeps lurking in the bottom-most workspace for when I am not coding  or somehow busy with a terminal window, or for when I really need access to a non-text attachment, which is seldom. I'll keep the VGA viewers, text-only mode and no window manager for the time when old age will make me really grumpy.

In this spirit, I am not going to insert the mandatory desktop snapshot (also: how do you snap on two monitors?) , but you can see my config (minus the color theme, that is). For the inquiring minds, I am on a Linux Fedora core 18 desktop, the mail server runs a Linux CentOS6 OS, with dovecot as mail server.

File ~/.muttrc
#----------------000-personal
set realname="Alessandro Forghieri"
my_hdr From: Alessandro Forghieri
set use_from = yes
set envelope_from = "yes"
#----------------010-imap
set spoolfile="imaps://alf@my.nyfty-imap-host.it/"
set folder="imaps://my.nyfty-imap-host.it/"
#I like my answers copied to inbox
set record="="
set postponed="=Drafts"
bind index "^" imap-fetch-mail
#----------------020-program
set edit_hdrs
set mailcap_path=~/.mutt/mailcap
auto_view text/html
alternative_order text/plain text/html
set editor=emacsclient
set sort=threads
set narrow_tree
#----------------090address-book and aliases
set query_command="goobook query '%s'"
macro index,pager A "goobook add" "add sender to google contacts"
bind editor complete-query
alias alf Alessandro Forghieri ;

File ~/.mutt/mailcap
audio/*; /usr/bin/xdg-open %s
image/*; /usr/bin/xdg-open %s
application/msword; /usr/bin/xdg-open %s
application/pdf; /usr/bin/xdg-open %s
application/postscript ; /usr/bin/xdg-open %s
text/html; elinks -dump %s ; copiousoutput;

File ~/.emacs (excerpt)

  (server-start)
  (add-to-list 'auto-mode-alist '("/mutt" . mail-mode))
  (defun my-mail-mode-hook ()
    (auto-fill-mode 1)
    (abbrev-mode 1)
    (local-set-key "\C-Xk" 'server-edit))
  (add-hook 'mail-mode-hook 'my-mail-mode-hook)