[PATCH v39 01/42] integrity: disassociate ima_filter_rule from security_audit_rule
Paul Moore
paul at paul-moore.com
Fri Jun 21 21:19:14 UTC 2024
On Fri, Jun 21, 2024 at 4:34 PM Roberto Sassu
<roberto.sassu at huaweicloud.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 at paul-moore.com> wrote:
> >>> On Fri, Dec 15, 2023 at 5:16 PM Casey Schaufler <casey at schaufler-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 at paul-moore.com>
> >>>> Reviewed-by: John Johansen <john.johansen at canonical.com>
> >>>> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>
> >>>> To: Mimi Zohar <zohar at linux.ibm.com>
> >>>> Cc: linux-integrity at vger.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.
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list