On Tue, 2013-07-09 at 11:21 -0400, Daniel J Walsh wrote:
On 07/09/2013 10:27 AM, Dominick Grift wrote:
> On Tue, 2013-07-09 at 21:28 +0800, Ed Greshko wrote:
>> On 07/09/13 21:06, Ed Greshko wrote:
>>
>>
>> Sorry to be responding to myself....but....
>>
>> It seems this AVC is the relevant one since /run is on tmpfs.
>>>
>>> type=AVC msg=audit(1373375040.246:775): avc: denied { write } for
>>> pid=3820 comm="fail2ban-client" name="fail2ban"
dev="tmpfs" ino=28732
>>> scontext=system_u:system_r:fail2ban_client_t:s0
>>> tcontext=system_u:object_r:fail2ban_var_run_t:s0 tclass=dir
>>
>> Not being fluent in selinux.... Would this be a bug in the fail2ban
>> policy module.... Or, something else?
>>
>
> yes a bug in the fail2ban policy module
>
> either the fail2ban client checks to see if /run/fail2ban is writable or it
> actually wants to create something in there ( but there is currently no
> trace of the latter)
I noticed that fedora uses the audit_access av perm wrong ( at least to
the best of my knowledge)
What fedora does:
dontaudit somedomain_t somefile_t:file audit_access;
How i believe it should be used:
dontaudit somedomain_t somefile_t:file write;
allow somedomain_t somefile_t:file audit_access;
Although, and i have not checked this, it sometimes seems that it does
not work either way. I still need to verify that. ( i might actually do
that now)
>
> -- selinux mailing list selinux(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>
It seems that fail2ban-client is doing a check to see if it can write there
before using the socket. Seems like a bogus check which we don't audited
before, but now seems to be causing problems.