service not starting via systemd but no AVCs are generated

[Dominick Grift]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/selinux/attachments/20130709/e072c1b9/attachment.sig>