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 23:52:22 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (121 lines)
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.  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

ATOM RSS1 RSS2