On Fri, Jun 21, 2024 at 4:34 PM Roberto Sassu
[off-list ref] wrote:

On 6/21/2024 10:23 PM, Mimi Zohar wrote:

quoted

On Fri, 2024-06-21 at 15:07 -0400, Paul Moore wrote:

quoted

On Fri, Jun 21, 2024 at 12:50 PM Paul Moore [off-list ref] wrote:

quoted

On Fri, Dec 15, 2023 at 5:16 PM Casey Schaufler [off-list ref] wrote:

quoted

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@paul-moore.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: linux-integrity@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