SCIENTIFIC-LINUX-USERS Archives

July 2017

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Reply To:
Date:
Mon, 17 Jul 2017 20:22:05 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (58 lines)
You could use audit to allow to see what you need to allow it:

cat /var/log/audit/audit.log | audit2allow.

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

ATOM RSS1 RSS2