service not starting via systemd but no AVCs are generated

[Dominick Grift]

On Tue, 2013-07-09 at 12:37 -0400, Eric Paris wrote:
> 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)
> 
> It is using it correctly.  audit_access is weird and special..
> 
> allow for the perm audit_access means nothing at all...
> 
> dontaudit somedomain_t somefile_t:file audit_access;
> 
> means we don't audit failures in the access(2) syscall, but we do audit
> failures on open/read/write...
> 
> We added this because nautilus does access(2) checks on every file in
> the world to decide how to display it on the screen.  We didn't want to
> hide users actually trying to open the file for read/write, but did want
> to hide all of the 'denials' from access(2)
> 
> Disabling dontaudit should make things show up even for access(2)....

So now that i know how to use it. it raises other questions.

Isnt silently denying access checks the world upside-down? If it should
not do access checks then should it not be fixed in the component rather
than silently hidden in policy.

If nautilus cannot perform access checks on files then it will put a big
fat lock and cross label on the icon representing the file.

I think apps generally do access checks for legitimate reasons and not
for their health.

So to me this is useless. I would rather have seen a new av perm for
access(2) checks if that would have been at all possible.

Now we have a av permission that is solely for dontaudit purposes. Sets
not such a good precedent.