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...
> 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.
What would that gain us? access(2) actually checks read/write/execute
and needs to return the correct results. A new perm on access(2)
doesn't seem to apply...
>Now we have a av permission that is solely for dontaudit purposes. Sets
> not such a good precedent.
That's exactly what it is. It is solely for dontaudit purposes. It's a
strange little beast, but seemed a better solution than dontaudit for
actual attempted use of a file...
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
