Wel is exim able to do what it is supposed to do as an
mta(transfer/transport mail) with selinux blocking this? If not you
could create a custom selinux policy for it. If it is able to do what is
supposed to and you aren't running into any unwanted results you can
just leave it. I got selinux blocking access to /proc/sys on a couple of
nagios checks via nrpe but it's not preventing the checks from working.

You could probably try to create it by doing something like this if exim
is not able to do it's job  by selinux blocking it:

ausearch -c 'exim' --raw |audit2allow -M mypol

then: semodule -i mypol.pp



On 07/17/2017 09:09 PM, Stephen Isard wrote:
> On Mon, 17 Jul 2017 20:22:05 +0200, Maarten <[log in to unmask]> wrote:
>
>> You could use audit to allow to see what you need to allow it:
>>
>> cat /var/log/audit/audit.log | audit2allow.
> Thanks, that helps.  The log entry recommends
> ausearch -c 'exim' --raw |audit2allow, so I've tried that and got
>
> libsepol.sepol_string_to_security_class: unrecognized class dir
>
> #========== exim_t ==============
> allow exim_t sysctl_net_t:dir search;
>
> /proc/sys/net, as opposed to /proc/net, is of type sysctl_net_t, so that may be where exim is trying to search.
> If so, the question is then why, and do I want it to.
>
>
>> This output my advise you to enable a certain boolean instead of
>> creating your own policy or changing the selinux context on a certain
>> dir structure.
>>
>> And then create your own selinux policy:
>>
>> cat /var/log/audit/audit.log | audit2allow -M mypol
>>
>> then install the policy via semodule -i mypol.pp
>>
>>
>> On 07/17/2017 08:15 PM, Stephen Isard wrote:
>>> On two SL7.3 systems where I have set exim as my mta alternative, I am
>>> getting a lot of entries in /var/log/messages saying "SELinux is
>>> preventing /usr/bin/exim from search access on the directory net",
>>> with the usual accompanying "if you believe that exim should be
>>> allowed..." stuff, but the logs don't explain what call to exim
>>> triggered the messages.
>>>
>>> Sealert -l tells me
>>>
>>> Raw Audit Messages
>>> type=AVC msg=audit(1500313603.937:268): avc:  denied { search } for
>>> pid=3097 comm="exim" name="net" dev="proc" ino=7154
>>> scontext=system_u:system_r:exim_t:s0
>>> tcontext=system_u:object_r:sysctl_net_t:s0 tclass=dir
>>>
>>> type=SYSCALL msg=audit(1500313603.937:268): arch=x86_64 syscall=open
>>> success=no exit=EACCES a0=7ff03baef4b0 a1=80000 a2=1b6 a3=24 items=0
>>> ppid=781 pid=3097 auid=4294967295 uid=0 gid=93 euid=0 suid=0 fsuid=0
>>> egid=93 sgid=93 fsgid=93 tty=(none) ses=4294967295 comm=exim
>>> exe=/usr/sbin/exim subj=system_u:system_r:exim_t:s0 key=(null)
>>>
>>> which doesn't seem to be much help.
>>>
>>> Searches turn up two Centos 7 reports,
>>> https://bugs.centos.org/view.php?id=13247 and
>>> https://bugs.centos.org/view.php?id=12913 that look as if they might
>>> be the same thing with different mta alternatives, but no response to
>>> either.
>>>
>>> All that the mta is supposed to be doing on these systems is reporting
>>> the output of cron jobs, and that appears to be happening correctly,
>>> so I am puzzled as to what this is about.  I'm not even sure what net
>>> directory is being referred to.  /proc/net?  Does an mta need to look
>>> in that directory?  I can send mail internally, to and from my local
>>> user and root, and that doesn't provoke selinux messages in the logs.
>>>
>>> Any suggestions for where to look?
>>>
>>> Thanks,
>>>
>>> Stephen Isard