/ Infrastructure

SETroubleshoot Email Notification on SELinux Denial

I've recently installed setroubleshoot-server on my RHEL6 server to help diagnose various SELinux denials as I attempt to secure the box.

SETroubleshoot also has an email notification system that is really easy to implement. There are a couple of things that you should consider before going forward.

Add the recipient email addresses to /var/lib/setroubleshoot/email_alert_recipients:

admin@example.com filter_type=after_first

Note: the after_first filter will prevent setroubleshoot from flooding your inbox with the same alert. There are other filter types, see the man page.

…and finally modify the [email] section in /etc/setroubleshoot/setroubleshoot.cfg:

# recipients_filepath: Path name of file with email recipients. One address
# per line, optionally followed by enable flag. Comment character is #.
recipients_filepath = /var/lib/setroubleshoot/email_alert_recipients

# smtp_port: The SMTP server port
smtp_port = 2525

# smtp_host: The SMTP server address
smtp_host = mail.example.com

# from_address: The From: email header
from_address = security@demon.local

In my case, my MTA is listening on port 2525 as well as port 25, due to most ISPs blocking 25. The RHEL server is behind such an ISP and I had to use this as the mail port.

By default, SELinux allows only a short list of ports to be used by the SMTP protocol, and when setroubleshoot tried to send the alert, I saw this in /var/log/messages:

Dec 14 16:41:58 demon setroubleshoot: [avc.ERROR] Plugin Exception httpd_bad_labels #012Traceback (most recent call last):#012 File "/usr/lib/python2.6/site-packages/setroubleshoot/analyze.py", line 156, in analyze_avc#012 report_receiver.report_problem(report)#012 File "/usr/lib/python2.6/site-packages/setroubleshoot/server.py", line 195, in report_problem#012 email_alert(siginfo, to_addrs)#012 File "/usr/lib/python2.6/site-packages/setroubleshoot/email_alert.py", line 77, in email_alert#012 smtp = smtplib.SMTP(smtp_host, smtp_port)#012 File "/usr/lib/python2.6/smtplib.py", line 239, in __init__#012 (code, msg) = self.connect(host, port)#012 File "/usr/lib/python2.6/smtplib.py", line 295, in connect#012 self.sock = self._get_socket(host, port, self.timeout)#012 File "/usr/lib/python2.6/smtplib.py", line 273, in _get_socket#012 return socket.create_connection((port, host), timeout)#012 File "/usr/lib/python2.6/socket.py", line 514, in create_connection#012 raise error, msg#012error: [Errno 13] Permission denied

…which basically means that the email_alert.py setroubleshoot script could not create an SMTP connection to my mail server on the port specified.

On RHEL/CentOS, these are the allowed SMTP ports:

[root@demon ~]# semanage port -l | grep smtp
smtp_port_t tcp 25, 465, 587

In order to allow demon.* to send mail to the remote MTA, I had to:

[root@demon ~]# semanage port -a -t smtp_port_t -p tcp 2525
[root@demon ~]# semanage port -l | grep smtp
smtp_port_t tcp 2525, 25, 465, 587

And that's it! You can quickly test by generating an SELinux denial and see if you get an email.

In my case, the remote MTA (running Exim) was dropping the messages and setroubleshoot would throw this in /var/log/messages:

Dec 17 09:53:19 demon setroubleshoot: [email.ERROR] email failed: {'admin@example.com': (550, 'Verification failed for <security@demon.local> The mail server could not deliver mail to security@demon.local. The account or domain may not exist, they may be blacklisted, or missing the proper dns entries. Sender verify failed')}

This was due to Exim+SpamAssassin performing callbacks or callouts to ensure that the From: email address is valid on the mail server it comes from.

I got around this by adding the RHEL6 server's IP block as a trusted mail provider. In /etc/mailproviders/ on the Exim server, I created the following tree:

root@exim [/etc/mailproviders]# tree
|-- rim
| `-- ips
`-- demon
`-- ips

2 directories, 2 files
root@exim [/etc/mailproviders]# cat demon/ips
root@exim [/etc/mailproviders]#

The ips files contain a list of IP blocks for Exim to trust as mail providers and add to the whitelist. This is probably not the safest solution but it is the quickest.

Warning: if you don't trust the entire IP block you can open your MTA to unchallenged spam.