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@xxxxxxxxxxxxxxxxxxxxxxx
> > 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.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
