On Tue, 2013-07-09 at 18:06 +0200, Dominick Grift wrote:
> 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)
So either i am not understanding audit_access or it just doesnt work.
I just tried it and here is a situation where i think audit_access
should apply:
type=SYSCALL msg=audit(07/09/2013 18:14:07.930:663) : arch=x86_64
syscall=access success=no exit=-13(Permission denied) a0=0x2b040a5
a1=X_OK a2=0x6e69622f a3=0x387da86b20 items=0 ppid=1836 pid=2090
auid=myloginuser uid=myloginuser gid=myloginuser euid=myloginuser
suid=myloginuser fsuid=myloginuser egid=myloginuser sgid=myloginuser
fsgid=myloginuser ses=2 tty=(none) comm=gnome-shell
exe=/usr/bin/gnome-shell
subj=myloginuser_u:myloginuser_r:myloginuser_gshell_t:s0 key=(null)
type=AVC msg=audit(07/09/2013 18:14:07.930:663) : avc: denied
{ execute } for pid=2090 comm=gnome-shell name=logfactor5 dev="dm-2"
ino=10236053
scontext=myloginuser_u:myloginuser_r:myloginuser_gshell_t:s0
tcontext=system_u:object_r:bin_t:s0 tclass=file
As you can se it checks access for X_OK, so a rule like:
allow myloginuser_gshell_t bin_t:file audit_access;
.. should make it succeed. But it doesnt
So i added another rule:
auditallow myloginuser_gshell_t bin_t:file audit_access;
.. to see if it actually hits that. But it doesnt.
So we end up with "success=no" and no proof that this audit_access av
permission was ever used.
push comes to show the access test fails, in resume: audit_access is
useless and broken, it doesnt work.
Attachment:
signature.asc
Description: This is a digitally signed message part
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
