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