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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhRLwL6cBSXsZF09HWspeREf_tKxh0QdX1Hki=DPvHv7Vg@mail.gmail.com>
Date:   Wed, 7 Sep 2022 16:23:49 -0400
From:   Paul Moore <paul@...l-moore.com>
To:     Steve Grubb <sgrubb@...hat.com>
Cc:     Richard Guy Briggs <rgb@...hat.com>, Jan Kara <jack@...e.cz>,
        Linux-Audit Mailing List <linux-audit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, Eric Paris <eparis@...isplace.org>,
        Amir Goldstein <amir73il@...il.com>
Subject: Re: [PATCH v4 3/4] fanotify,audit: Allow audit to use the full
 permission event response

On Wed, Sep 7, 2022 at 4:11 PM Steve Grubb <sgrubb@...hat.com> wrote:
> On Wednesday, September 7, 2022 2:43:54 PM EDT Richard Guy Briggs wrote:
> > > > Ultimately I guess I'll leave it upto audit subsystem what it wants to
> > > > have in its struct fanotify_response_info_audit_rule because for
> > > > fanotify subsystem, it is just an opaque blob it is passing.
> > >
> > > In that case, let's stick with leveraging the type/len fields in the
> > > fanotify_response_info_header struct, that should give us all the
> > > flexibility we need.
> > >
> > > Richard and Steve, it sounds like Steve is already aware of additional
> > > information that he wants to send via the
> > > fanotify_response_info_audit_rule struct, please include that in the
> > > next revision of this patchset.  I don't want to get this merged and
> > > then soon after have to hack in additional info.
> >
> > Steve, please define the type and name of this additional field.
>
> Maybe extra_data, app_data, or extra_info. Something generic that can be
> reused by any application. Default to 0 if not present.

I think the point is being missed ... The idea is to not speculate on
additional fields, as discussed we have ways to handle that, the issue
was that Steve implied that he already had ideas for "things" he
wanted to add.  If there are "things" that need to be added, let's do
that now, however if there is just speculation that maybe someday we
might need to add something else we can leave that until later.

-- 
paul-moore.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ