On Mon, 17 Jul 2017 23:52:22 +0200, Maarten <mailingli...@feedmebits.nl> 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 <mailingli...@feedmebits.nl> >> 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 <mailingli...@feedmebits.nl> >>>> 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