From: Paul Moore <paul@paul-moore.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Linux Security Module list
<linux-security-module@vger.kernel.org>,
"linux-audit@redhat.com" <linux-audit@redhat.com>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
Mimi Zohar <zohar@linux.ibm.com>
Subject: Re: Disassociating ima_filter_rule* from security_audit_rule*
Date: Thu, 4 Nov 2021 14:57:28 -0400 [thread overview]
Message-ID: <CAHC9VhSDXYfd3uZoFM=+onQcz=oM+3ZUr875SYvkDqhJA-QkWA@mail.gmail.com> (raw)
In-Reply-To: <ef82b8f5-082c-d2c5-2781-8a6bd90306cd@schaufler-ca.com>
On Thu, Nov 4, 2021 at 1:35 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> After the last round of comments on the LSM stacking patches
> Dmitry Mastykin <dmastykin@astralinux.ru> pointed out a
> conundrum with reuse of the security_audit_rule functions
> in integrity rule processing. The audit system wants to
> match rules for any security module that as one. The
> integrity system wants to match rules for a single, explicitly
> defined LSM. The two sub-systems use common code in security.c
> which needs to be changed to support multiple LSMs, but needs
> to be changed differently for each of these cases. While it
> would be possible to create frankensteinish versions of the
> security_audit_rule functions that would handle both cases
> it seems that creating "real" versions of the ima_filter_rule
> functions would be considerably cleaner and easier to maintain
> going forward.
>
> I'm suggesting this now, while I'm still working on the patches,
> in case there's a solid reason that frankencode is absolutely
> everybody's favored approach. I plan to propose the disassociation
> as a patch separate from and in advance of the stacking series.
I'm not 100% clear on what you are talking about, but since you are
currently working on the next revision to the LSM stacking patchset
perhaps it's best to just wait and see what the code looks like.
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
prev parent reply other threads:[~2021-11-04 19:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ef82b8f5-082c-d2c5-2781-8a6bd90306cd.ref@schaufler-ca.com>
2021-11-04 17:34 ` Disassociating ima_filter_rule* from security_audit_rule* Casey Schaufler
2021-11-04 18:57 ` Paul Moore [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHC9VhSDXYfd3uZoFM=+onQcz=oM+3ZUr875SYvkDqhJA-QkWA@mail.gmail.com' \
--to=paul@paul-moore.com \
--cc=casey@schaufler-ca.com \
--cc=linux-audit@redhat.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).