From: Mimi Zohar <zohar@linux.ibm.com>
To: Coiby Xu <coxu@redhat.com>
Cc: linux-integrity@vger.kernel.org,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Karel Srot <ksrot@redhat.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Eric Snowberg <eric.snowberg@oracle.com>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"open list:SECURITY SUBSYSTEM"
<linux-security-module@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ima: Fall back to default kernel module signature verification
Date: Mon, 20 Oct 2025 08:21:49 -0400 [thread overview]
Message-ID: <559f6ebf4a19da321fffc2a3ca180dc3d6216a22.camel@linux.ibm.com> (raw)
In-Reply-To: <z6f4getlayaxaxvlxfxn2yvn5dvhrct64wke4uu2s3dfll3bqq@754bklrku55n>
On Sat, 2025-10-18 at 07:19 +0800, Coiby Xu wrote:
> > > > 2. Instead of defining an additional process_measurement() argument to identify
> > > > compressed kernel modules, to simplify the code it might be possible to define a
> > > > new "func" named COMPRESSED_MODULE_CHECK.
> > > >
> > > > + [READING_COMPRESSED_MODULE] = MODULE_CHECK, -> COMPRESSED_MODULE_CHECK
> > >
> > > I also thought about this approach. But IMA rule maps kernel module
> > > loading to MODULE_CHECK. If we define a new rule and ask users to use
> > > this new rule, ima_policy=secure_boot still won't work.
> >
> > I don't have a problem with extending the "secure-boot" policy to support
> > uncompressed kernel modules appended signatures, based on whether
> > CONFIG_MODULE_SIG is enabled. The new rule would be in addition to the existing
> > MODULE_CHECK rule.
>
> I assume once the new rule get added, we can't remove it for userspace
> backward compatibility, right? And with CPIO xattr supported, it seems
> there is no need to keep this rule. So if this concern is valid, do you
> think we shall switch to another approach i.e. to make IMA support
> verifying decompressed module and then make "secure-boot" to allow
> appended module signature?
Yes, once the rule is added, it wouldn't be removed. As for "to make IMA
support verifying decompressed module", yes that might be a better solution,
than relying on "sig_enforce" being enabled. IMA already supports verifying the
appended signatures. A new IMA specific or LSM hook would need to be defined
after module_decompress().
Remember based on policy, IMA supports:
1. verifying the signature stored in security.ima xattr
2. verifying the appended signature (not for compressed kernel modules)
3. verifying both the xattr and appended signatures
4. none
To prevent 3 - verifying both types of signatures, the IMA arch specific policy
rule only adds the "appraise func=MODULE_CHECK ..." rule if CONFIG_MODULE_SIG is
NOT enabled. Calling set_module_sig_enforced() from ima_appraise_measurement()
to set sig_enforce could inadvertently result in requiring both the xattr and
the appended signature kernel module verification. To prevent this from
happening, "sig_enforce" should not be set, only verified in
ima_appraise_measurement().
>
> Another thought is to make CPIO support xattr. Today I realize that
> ima_policy=secure_boot can also cause failure of loading kdump kernel.
> So the issue this patch tries to resolves has much less impact than I
> thought. Maybe we can wait until CPIO xattr support is ready? I'll help
> review and test Roberto's patches if this is the best way forward.
I'm not sure of the status of the CPIO patch set. Roberto?
Mimi
next prev parent reply other threads:[~2025-10-20 12:22 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-28 3:03 [PATCH] ima: Fall back to default kernel module signature verification Coiby Xu
2025-09-30 13:57 ` Mimi Zohar
2025-09-30 20:28 ` Mimi Zohar
2025-10-16 3:46 ` Coiby Xu
2025-10-17 2:31 ` Mimi Zohar
2025-10-17 3:19 ` Coiby Xu
2025-10-17 17:49 ` Mimi Zohar
2025-10-17 23:19 ` Coiby Xu
2025-10-20 12:21 ` Mimi Zohar [this message]
2025-10-20 12:45 ` Roberto Sassu
2025-10-20 13:57 ` Mimi Zohar
2025-10-30 0:33 ` Coiby Xu
2025-10-24 15:16 ` Mimi Zohar
2025-10-30 0:31 ` Coiby Xu
2025-10-30 3:01 ` Mimi Zohar
2025-10-30 13:42 ` Coiby Xu
2025-10-30 16:50 ` Mimi Zohar
2025-10-31 7:58 ` Coiby Xu
2025-10-02 17:17 ` kernel test robot
2025-10-16 3:51 ` Coiby Xu
2025-10-31 7:40 ` [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module Coiby Xu
2025-11-01 16:50 ` Paul Moore
2025-11-02 15:05 ` Mimi Zohar
2025-11-02 15:43 ` Paul Moore
2025-11-05 0:18 ` Coiby Xu
2025-11-05 2:47 ` Paul Moore
2025-11-05 14:07 ` Mimi Zohar
2025-11-05 15:42 ` Paul Moore
2025-11-05 20:25 ` Mimi Zohar
2025-11-06 13:35 ` Coiby Xu
2025-11-05 20:47 ` Mimi Zohar
2025-11-06 13:29 ` Coiby Xu
2025-11-06 22:15 ` Mimi Zohar
2025-11-07 19:28 ` Mimi Zohar
2025-11-13 4:06 ` Coiby Xu
2025-11-18 12:19 ` Mimi Zohar
2025-11-19 3:52 ` Coiby Xu
2025-11-19 3:47 ` [PATCH v3] ima: Access decompressed kernel module to verify appended signature Coiby Xu
2025-11-19 13:29 ` Mimi Zohar
2025-11-19 14:05 ` Coiby Xu
2025-11-19 14:03 ` [PATCH v4] " Coiby Xu
2025-11-19 15:29 ` Mimi Zohar
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=559f6ebf4a19da321fffc2a3ca180dc3d6216a22.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=coxu@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=jmorris@namei.org \
--cc=ksrot@redhat.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.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 NNTP newsgroup(s).