On Wed, Feb 8, 2023 at 10:27 AM Steve Grubb <sgrubb(a)redhat.com> wrote:
On Wednesday, February 8, 2023 10:03:24 AM EST Paul Moore wrote:
> On Wed, Feb 8, 2023 at 7:08 AM Jan Kara <jack(a)suse.cz> wrote:
> > On Tue 07-02-23 09:54:11, Paul Moore wrote:
> > > On Tue, Feb 7, 2023 at 7:09 AM Jan Kara <jack(a)suse.cz> wrote:
> > > > On Fri 03-02-23 16:35:13, Richard Guy Briggs wrote:
> > > > > The Fanotify API can be used for access control by requesting
> > > > > permission
> > > > > event notification. The user space tooling that uses it may have
a
> > > > > complicated policy that inherently contains additional context
for
> > > > > the
> > > > > decision. If this information were available in the audit
trail,
> > > > > policy
> > > > > writers can close the loop on debugging policy. Also, if this
> > > > > additional
> > > > > information were available, it would enable the creation of
tools
> > > > > that
> > > > > can suggest changes to the policy similar to how audit2allow
can
> > > > > help
> > > > > refine labeled security.
> > > > >
> > > > > This patchset defines a new flag (FAN_INFO) and new extensions
that
> > > > > define additional information which are appended after the
response
> > > > > structure returned from user space on a permission event. The
> > > > > appended
> > > > > information is organized with headers containing a type and
size
> > > > > that
> > > > > can be delegated to interested subsystems. One new information
> > > > > type is
> > > > > defined to audit the triggering rule number.
> > > > >
> > > > > A newer kernel will work with an older userspace and an older
> > > > > kernel
> > > > > will behave as expected and reject a newer userspace, leaving it
up
> > > > > to
> > > > > the newer userspace to test appropriately and adapt as
necessary.
> > > > > This
> > > > > is done by providing a a fully-formed FAN_INFO extension but
> > > > > setting the
> > > > > fd to FAN_NOFD. On a capable kernel, it will succeed but issue
no
> > > > > audit
> > > > > record, whereas on an older kernel it will fail.
> > > > >
> > > > > The audit function was updated to log the additional information
in
> > > > > the
> > > > > AUDIT_FANOTIFY record. The following are examples of the new
record
> > > > >
> > > > > format:
> > > > > type=FANOTIFY msg=audit(1600385147.372:590): resp=2
fan_type=1
> > > > > fan_info=3137 subj_trust=3 obj_trust=5 type=FANOTIFY
> > > > > msg=audit(1659730979.839:284): resp=1 fan_type=0 fan_info=0
> > > > > subj_trust=2 obj_trust=2> > >
> > > > Thanks! I've applied this series to my tree.
> > >
> > > While I think this version of the patchset is fine, for future
> > > reference it would have been nice if you had waited for my ACK on
> > > patch 3/3; while Steve maintains his userspace tools, I'm the one
> > > responsible for maintaining the Linux Kernel's audit subsystem.
> >
> > Aha, I'm sorry for that. I had the impression that on the last version of
> > the series you've said you don't see anything for which the series
should
> > be respun so once Steve's objections where addressed and you were silent
> > for a few days, I thought you consider the thing settled... My bad.
>
> That's understandable, especially given inconsistencies across
> subsystems. If it helps, if I'm going to ACK something I make it
> explicit with a proper 'Acked-by: ...' line in my reply; if I say
> something looks good but there is no explicit ACK, there is usually
> something outstanding that needs to be resolved, e.g. questions,
> additional testing, etc.
>
> In this particular case I posed some questions in that thread and
> never saw a reply with any answers, hence the lack of an ACK. While I
> think the patches were reasonable, I withheld my ACK until the
> questions were answered ... which they never were from what I can
> tell, we just saw a new patchset with changes.
>
> /me shrugs
Paul,
I reread the thread. You only had a request to change if/else to a switch
construct only if there was a respin for the 3F. You otherwise said get
Steve's input and the 3F borders on being overly clever. Both were addressed.
If you had other questions that needed answers on, please restate them to
expedite approval of this set of patches. As far as I can tell, all comments
are addressed.
Steve,
It might be helpful to reread my reply below:
https://lore.kernel.org/linux-audit/CAHC9VhRWDD6Tk6AEmgoobBkcVKRYbVOte7-F...
You'll see that I made a comment in that email about not following
Richard's explanation about "encoding the zero" (the patch was
encoding a "?" to the best I could tell). I was hoping for some
clarification from Richard on his comments, and I never saw anything
in my inbox. I just checked the archives on lore and I don't see
anything there either.
--
paul-moore.com