[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aecad5ea129946dbf9cf5013331f9368ceb84326.camel@huaweicloud.com>
Date: Mon, 24 Jun 2024 10:45:59 +0200
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Paul Moore <paul@...l-moore.com>
Cc: Mimi Zohar <zohar@...ux.ibm.com>, Roberto Sassu
<roberto.sassu@...wei.com>, linux-security-module@...r.kernel.org,
jmorris@...ei.org, serge@...lyn.com, keescook@...omium.org,
john.johansen@...onical.com, penguin-kernel@...ove.sakura.ne.jp,
stephen.smalley.work@...il.com, linux-kernel@...r.kernel.org,
mic@...ikod.net, linux-integrity@...r.kernel.org, Casey Schaufler
<casey@...aufler-ca.com>
Subject: Re: [PATCH v39 01/42] integrity: disassociate ima_filter_rule from
security_audit_rule
On Fri, 2024-06-21 at 17:19 -0400, Paul Moore wrote:
> On Fri, Jun 21, 2024 at 4:34 PM Roberto Sassu
> <roberto.sassu@...weicloud.com> wrote:
> > On 6/21/2024 10:23 PM, Mimi Zohar wrote:
> > > On Fri, 2024-06-21 at 15:07 -0400, Paul Moore wrote:
> > > > On Fri, Jun 21, 2024 at 12:50 PM Paul Moore <paul@...l-moore.com> wrote:
> > > > > On Fri, Dec 15, 2023 at 5:16 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
> > > > > > Create real functions for the ima_filter_rule interfaces.
> > > > > > These replace #defines that obscure the reuse of audit
> > > > > > interfaces. The new functions are put in security.c because
> > > > > > they use security module registered hooks that we don't
> > > > > > want exported.
> > > > > >
> > > > > > Acked-by: Paul Moore <paul@...l-moore.com>
> > > > > > Reviewed-by: John Johansen <john.johansen@...onical.com>
> > > > > > Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
> > > > > > To: Mimi Zohar <zohar@...ux.ibm.com>
> > > > > > Cc: linux-integrity@...r.kernel.org
> > > > > > ---
> > > > > > include/linux/security.h | 24 ++++++++++++++++++++++++
> > > > > > security/integrity/ima/ima.h | 26 --------------------------
> > > > > > security/security.c | 21 +++++++++++++++++++++
> > > > > > 3 files changed, 45 insertions(+), 26 deletions(-)
> > > > >
> > > > > Mimi, Roberto, are you both okay if I merge this into the lsm/dev
> > > > > branch? The #define approach taken with the ima_filter_rule_XXX
> > > > > macros likely contributed to the recent problem where the build
> > > > > problem caused by the new gfp_t parameter was missed during review;
> > > > > I'd like to get this into an upstream tree independent of the larger
> > > > > stacking effort as I believe it has standalone value.
> > > >
> > > > ... and I just realized neither Mimi or Roberto were directly CC'd on
> > > > that last email, oops. Fixed.
> > >
> > > Paul, I do see things posted on the linux-integrity mailing list pretty quickly.
> > > Unfortunately, something came up midday and I'm just seeing this now. As for
> > > Roberto, it's probably a time zone issue.
> >
> > Will review/check it first thing Monday morning.
>
> Thanks Roberto, no rush.
Ok, so no problem from my side to upstream the patch.
My only comment would be that I would not call the new functions with
the ima_ prefix, being those in security.c, which is LSM agnostic, but
I would rather use a name that more resembles the differences, if any.
If not:
Acked-by: Roberto Sassu <roberto.sassu@...wei.com>
Thanks
Roberto
Powered by blists - more mailing lists