From: Coiby Xu <coxu@redhat.com>
To: linux-integrity@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Karel Srot <ksrot@redhat.com>, Mimi Zohar <zohar@linux.ibm.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>,
linux-security-module@vger.kernel.org (open list:SECURITY
SUBSYSTEM), linux-kernel@vger.kernel.org (open list)
Subject: [PATCH] ima: Fall back to default kernel module signature verification
Date: Sun, 28 Sep 2025 11:03:58 +0800 [thread overview]
Message-ID: <20250928030358.3873311-1-coxu@redhat.com> (raw)
Currently, for any IMA policy that requires appraisal for kernel modules
e.g. ima_policy=secure_boot, PowerPC architecture specific policy,
booting will fail because IMA will reject a kernel module which will
be decompressed in the kernel space and then have its signature
verified.
This happens because when in-kernel module decompression
(CONFIG_MODULE_DECOMPRESS) is enabled, kmod will use finit_module
syscall instead of init_module to load a module. And IMA mandates IMA
xattr verification for finit_module unless appraise_type=imasig|modsig
is specified in the rule. However currently initramfs doesn't support
xattr. And IMA rule "func=MODULE_CHECK appraise_type=imasig|modsig"
doesn't work either because IMA will treat to-be-decompressed kernel
module as not having module signature as it can't decompress kernel
module to check if signature exists.
So fall back to default kernel module signature verification when we have
no way to verify IMA xattr.
Reported-by: Karel Srot <ksrot@redhat.com>
Signed-off-by: Coiby Xu <coxu@redhat.com>
---
Another approach will be to make IMA decompress the kernel module to
check the signature. This requires refactoring kernel module code to
make the in-kernel module decompressing feature modular and seemingly
more efforts are needed. A second disadvantage is it feels
counter-intuitive to verify the same kernel module signature twice. And
we still need to make ima_policy=secure_boot allow verifying appended
module signature.
Anyways, I'm open to suggestions and can try the latter approach if
there are some benefits I'm not aware of or a better approach.
security/integrity/ima/ima_appraise.c | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
index f435eff4667f..fcc75dd1486f 100644
--- a/security/integrity/ima/ima_appraise.c
+++ b/security/integrity/ima/ima_appraise.c
@@ -502,9 +502,10 @@ int ima_appraise_measurement(enum ima_hooks func, struct ima_iint_cache *iint,
enum integrity_status status = INTEGRITY_UNKNOWN;
int rc = xattr_len;
bool try_modsig = iint->flags & IMA_MODSIG_ALLOWED && modsig;
+ bool enforce_module_sig = iint->flags & IMA_DIGSIG_REQUIRED && func == MODULE_CHECK;
- /* If not appraising a modsig, we need an xattr. */
- if (!(inode->i_opflags & IOP_XATTR) && !try_modsig)
+ /* If not appraising a modsig or using default module verification, we need an xattr. */
+ if (!(inode->i_opflags & IOP_XATTR) && !try_modsig && !enforce_module_sig)
return INTEGRITY_UNKNOWN;
/*
@@ -517,8 +518,8 @@ int ima_appraise_measurement(enum ima_hooks func, struct ima_iint_cache *iint,
if (is_bprm_creds_for_exec(func, file))
audit_msgno = AUDIT_INTEGRITY_USERSPACE;
- /* If reading the xattr failed and there's no modsig, error out. */
- if (rc <= 0 && !try_modsig) {
+ /* If reading the xattr failed and there's no modsig or module verification, error out. */
+ if (rc <= 0 && !try_modsig && !enforce_module_sig) {
if (rc && rc != -ENODATA)
goto out;
@@ -549,8 +550,8 @@ int ima_appraise_measurement(enum ima_hooks func, struct ima_iint_cache *iint,
case INTEGRITY_UNKNOWN:
break;
case INTEGRITY_NOXATTRS: /* No EVM protected xattrs. */
- /* It's fine not to have xattrs when using a modsig. */
- if (try_modsig)
+ /* Fine to not have xattrs when using a modsig or default module verification. */
+ if (try_modsig || enforce_module_sig)
break;
fallthrough;
case INTEGRITY_NOLABEL: /* No security.evm xattr. */
@@ -580,6 +581,18 @@ int ima_appraise_measurement(enum ima_hooks func, struct ima_iint_cache *iint,
rc == -ENOKEY))
rc = modsig_verify(func, modsig, &status, &cause);
+ /* Fall back to default kernel module signature verification */
+ if (rc && enforce_module_sig) {
+ rc = 0;
+ set_module_sig_enforced();
+ /* CONFIG_MODULE_SIG may be disabled */
+ if (is_module_sig_enforced()) {
+ rc = 0;
+ status = INTEGRITY_PASS;
+ pr_debug("Fall back to default kernel module verification for %s\n", filename);
+ }
+ }
+
out:
/*
* File signatures on some filesystems can not be properly verified.
base-commit: cec1e6e5d1ab33403b809f79cd20d6aff124ccfe
--
2.51.0
next reply other threads:[~2025-09-28 3:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-28 3:03 Coiby Xu [this message]
2025-09-30 13:57 ` [PATCH] ima: Fall back to default kernel module signature verification Mimi Zohar
2025-09-30 20:28 ` Mimi Zohar
2025-10-02 17:17 ` kernel test robot
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=20250928030358.3873311-1-coxu@redhat.com \
--to=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 \
--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 NNTP newsgroup(s).