rsyslog ommail doesn't work with SELinux enabled

February 20th at 12:00am

I setup a new Centos 7 box yesterday and configured rsyslog to send me an email whenever there is a successful authentication attempt. The funny thing was that no email would get sent when rsyslog was run as a service, yet when I ran it directly from the command line it seemed to work correctly.

In digging deeper I found that SELinux was blocking syslog from sending emails and was able to resolve it with a few configuration changes.

I setup a new Centos 7 box yesterday and configured rsyslog to send me an email whenever there is a successful authentication attempt. The funny thing was that no email would get sent when rsyslog was run as a service, yet when I ran it directly from the command line it seemed to work correctly.

In digging deeper I found that SELinux was blocking syslog from sending emails and was able to resolve it with a few configuration changes.

References

 

Troubleshooting SELinux

The first thing I did was configure SELinux to let syslog send emails:

setsebool -P logging_syslogd_can_sendmail=1

Unfortunately this wasn't quite enough to solve the problem. My ISP blocks port 25, so I had to configure ommail to use port 26 to send emails instead. SELinux does not like that, so I decided to run the audit2why utility to get a basic idea of what was going on. By running audit2why -w -a I received this output:

type=AVC msg=audit(1455653771.298:493): avc: denied { name_connect } for pid=27709 comm=72733A6D61696E20513A526567 dest=26 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket

Was caused by:
The boolean nis_enabled was set incorrectly.
Description:
Allow nis to enabled

Allow access by executing:
# setsebool -P nis_enabled 1

The output of this message indicates that I can get past the problem by enabling the nis_enabled SELinux bool. Sure enough, by running setsebool -P nis_enabled 1 I was able to get ommail to function correctly- but I disabled it using setsebool -P nis_enabled 0 since I don't use NIS on this box so enabling NIS SELinux options seems a bit excessive.

The How do I tell what would be allowed by a boolean? article I referenced above includes useful commands that you can run to find out the impact of enabling an SELinux boolean. Using those commands as a reference, I crafted this to help me understand the impact of enabling the nis_enabled boolean:

sesearch -A -s syslogd_t -b nis_enabled

The output of the command is pretty dry- it lists over 30 rules that would be enabled which seems a bit excessive to just allow ommail to send an email over port 26.

 

Creating my own SELinux policy

After determining that enabling NIS SELinux rules would not work for my situation I read one of the other articles I referenced titled Using audit2allow to build policy modules. Revisited. to figure out how to create a more targeted SELinux policy that just lets rsyslog send emails over an alternate port.

This is what I ended up doing:

  • sudo su -
  • mkdir selinux_policies
  • cd selinux_policies
  • audit2allow -M myrsyslog < /var/log/audit/audit.log

Paraphrasing the above: login as root, create a location where I can store SELinux policies, create a new policy using audit2allow (see the referenced article for more details).

The above commands created 2 new files: myrsyslog.te and myrsyslog.pp. The .te file is human readable where the .pp file is a compiled policy. This is what my human readable policy looks like:

module myrsyslog 1.0;

require {
type syslogd_t;
type reserved_port_t;
class tcp_socket name_connect;
}

#============= syslogd_t ==============

#!!!! This avc can be allowed using the boolean 'nis_enabled'
allow syslogd_t reserved_port_t:tcp_socket name_connect;

 

As you can see, there is nowhere near the 30+ rules here that are included in the 'NIS' ruleset. Interestingly enough, audit2allow includes a comment in the generated policy file that lets you know about the nis_enabled boolean. I like that it includes the comment as it gives you something else to investigate before implementing your own policy.

With my new policy in hand, the last thing to do is enable it:

semodule -i myrsyslog.pp

Then verify that it has been enabled:

semodule -l | grep myrsyslog

(You can tell the policy is enabled if it shows up in the semodule listing)

 

A quick experiement shows that rsyslog's ommail can send an email when someone successfully authenticates, so mission accomplished!