service not starting via systemd but no AVCs are generated

[Dominick Grift]

On Tue, 2013-07-09 at 14:13 -0400, Eric Paris wrote:
> On Tue, 2013-07-09 at 19:35 +0200, Dominick Grift wrote:
> > 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.
> 
> It is very very weird.  I agree.
> 
> > 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.
> 
> You can't 'fix' nautilis.  It needs to ask if it has read/write/execute
> permission to do its job.  So I'm left with the choice of dontaudit-ing
> read/write/execute from nautilus to everything or using this special
> little bit of hackery to allowed access(2) to not spam the logs but to
> get the right result.
> 
> You'll still get the read/write/execute denial if you try to DO anything
> with the file.  Which you wouldn't if one were to do the dontaudit-ing
> directly.
> 
> > 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.
> 
> That's right.  We want that lock to be able to be showed without
> spamming the logs...
> 
> > I think apps generally do access checks for legitimate reasons and not
> > for their health.
> 
> except nautilus...

Ok yes, it is starting to make a little sense to me. Although to me it
still doesnt seem quite worth it because if nautilus wants to for
example really execute or write a file then it would first need to be
able to open it.

and you know similar stuff is also happening with leaked fds in a sense.
where legitimate read writes are dontaudited because they may be related
to leaks ( which they often arent )

so for example:
# sesearch --dontaudit -s domain -t domain -c unix_stream_socket -p
read,write | grep " domain domain"
   dontaudit domain domain : unix_stream_socket { read write } ; 

i guess in a perfect world we would have a "audit_access" for that as
well so that legitimate { read write } would be logged while ones
related to leaked fd would be dontaudited ( but i bet thats technically
impossible).

But anyways i get the point now and i dont think i will use it much.

I tried it with nautilus and i was able to just dontaudit the checks
with no problems so far and no need for audit_access ( although i did
changed it now to audit_access just because i can )

Thanks for having this discussion with me