On Mon, 17 Jul 2017 23:52:22 +0200, Maarten <[log in to unmask]> wrote:

>The process exim running with the the selinux context exim_t is trying
>to access the directory /proc/net which has the selinux context
>sysctl_net_t.
>
>Causing selinux to block access to directory, because the source context
>is different from the destination context. 

Yes, thank you, I've got that part.  As I said earlier, what I am wondering now is why exim is trying to search that directory, and whether I want it to.
It happens at - to me - unpredictable times, apparently unrelated to any messages being sent or received.

> Redhat has a package that
>updates
>
>all the active selinux policies on the system, I think it is
>selinux-policy-targeted they update the policies  every now they update
>the selinux policies. I would
>
>think they make policies for everything from the base repos. Exim is
>from epel en so is the nrpe package(which I'm getting the selinux
>messages from).  I don't know
>
>how selinux policies are managed for packages outside of the base repos.
>That's probably why there are multiple ways to manage selinux with
>custom policies, booleans, and selinux contexts etc. Maybe someone else
>knows how selinux policies for packages in third party repos are
>managed? Does that help?
>
>Cheers,
>
>Maarten
>
>
>On 07/17/2017 11:02 PM, Stephen Isard wrote:
>> On Mon, 17 Jul 2017 21:33:29 +0200, Maarten <[log in to unmask]> wrote:
>>
>>> 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.
>> Indeed, but I would still prefer to understand what is going on.
>>
>>> 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