linux-kernel - Re: [PATCH v2] io_uring,audit: don't log IORING_OP

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: <CAHC9VhTNb4gOpk9=49-ABtYs1DFKqqwXPSc-2bhJX7wcZ82o=g@mail.gmail.com>
Date:   Thu, 9 Feb 2023 17:37:22 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Richard Guy Briggs <rgb@...hat.com>
Cc:     Linux-Audit Mailing List <linux-audit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>, io-uring@...r.kernel.org,
        Eric Paris <eparis@...isplace.org>,
        Steve Grubb <sgrubb@...hat.com>,
        Christian Brauner <brauner@...nel.org>,
        Stefan Roesch <shr@...com>
Subject: Re: [PATCH v2] io_uring,audit: don't log IORING_OP_MADVISE

On Thu, Feb 9, 2023 at 4:53 PM Richard Guy Briggs <rgb@...hat.com> wrote:
> On 2023-02-01 16:18, Paul Moore wrote:
> > On Wed, Feb 1, 2023 at 3:34 PM Richard Guy Briggs <rgb@...hat.com> wrote:
> > > fadvise and madvise both provide hints for caching or access pattern for
> > > file and memory respectively.  Skip them.
> >
> > You forgot to update the first sentence in the commit description :/
>
> I didn't forget.  I updated that sentence to reflect the fact that the
> two should be treated similarly rather than differently.

Ooookay.  Can we at least agree that the commit description should be
rephrased to make it clear that the patch only adjusts madvise?  Right
now I read the commit description and it sounds like you are adjusting
the behavior for both fadvise and madvise in this patch, which is not
true.

> > I'm still looking for some type of statement that you've done some
> > homework on the IORING_OP_MADVISE case to ensure that it doesn't end
> > up calling into the LSM, see my previous emails on this.  I need more
> > than "Steve told me to do this".
> >
> > I basically just want to see that some care and thought has gone into
> > this patch to verify it is correct and good.
>
> Steve suggested I look into a number of iouring ops.  I looked at the
> description code and agreed that it wasn't necessary to audit madvise.
> The rationale for fadvise was detemined to have been conflated with
> fallocate and subsequently dropped.  Steve also suggested a number of
> others and after investigation I decided that their current state was
> correct.  *getxattr you've advised against, so it was dropped.  It
> appears fewer modifications were necessary than originally suspected.

My concern is that three of the four changes you initially proposed
were rejected, which gives me pause about the fourth.  You mention
that based on your reading of madvise's description you feel auditing
isn't necessary - and you may be right - but based on our experience
so far with this patchset I would like to hear that you have properly
investigated all of the madvise code paths, and I would like that in
the commit description.

-- 
paul-moore.com