linux-kernel - Re: [PATCH v7 0/3] fanotify: Allow user space to pass back additional audit info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230209090750.lx32p57jtul7pnv5@quack3>
Date:   Thu, 9 Feb 2023 10:07:50 +0100
From:   Jan Kara <jack@...e.cz>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Jan Kara <jack@...e.cz>, Richard Guy Briggs <rgb@...hat.com>,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, linux-api@...r.kernel.org,
        Eric Paris <eparis@...isplace.org>,
        Steve Grubb <sgrubb@...hat.com>,
        Amir Goldstein <amir73il@...il.com>
Subject: Re: [PATCH v7 0/3] fanotify: Allow user space to pass back
 additional audit info

On Wed 08-02-23 10:03:24, Paul Moore wrote:
> On Wed, Feb 8, 2023 at 7:08 AM Jan Kara <jack@...e.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@...e.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.

Ok, thanks for letting me now. Next time I'll wait for an explicit ack from
you. This time, since everybody is fine with the actual patch, let's just
move on ;).

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR