From: Mimi Zohar <zohar@linux.ibm.com>
To: Paul Moore <paul@paul-moore.com>, Coiby Xu <coxu@redhat.com>
Cc: linux-integrity@vger.kernel.org,
linux-security-module@vger.kernel.org,
Karel Srot <ksrot@redhat.com>, James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Petr Pavlu <petr.pavlu@suse.com>,
Daniel Gomez <da.gomez@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Roberto Sassu <roberto.sassu@huawei.com>,
Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
Eric Snowberg <eric.snowberg@oracle.com>,
open list <linux-kernel@vger.kernel.org>,
"open list:MODULE SUPPORT" <linux-modules@vger.kernel.org>
Subject: Re: [PATCH v2] lsm,ima: new LSM hook security_kernel_module_read_file to access decompressed kernel module
Date: Sun, 02 Nov 2025 10:05:31 -0500 [thread overview]
Message-ID: <baa39fcd1b6b485f14b8f06dcd96b81359e6e491.camel@linux.ibm.com> (raw)
In-Reply-To: <CAHC9VhRBXkW+XuqhxJvEOYR_VMxFh4TRWUtXzZky=AG_nyBYEQ@mail.gmail.com>
On Sat, 2025-11-01 at 12:50 -0400, Paul Moore wrote:
> On Fri, Oct 31, 2025 at 3:41 AM Coiby Xu <coxu@redhat.com> wrote:
> >
> > Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS)
> > is enabled, IMA has no way to verify the appended module signature as it
> > can't decompress the module.
> >
> > Define a new LSM hook security_kernel_module_read_file which will be
> > called after kernel module decompression is done so IMA can access the
> > decompressed kernel module to verify the appended signature.
> >
> > Since IMA can access both xattr and appended kernel module signature
> > with the new LSM hook, it no longer uses the security_kernel_post_read_file
> > LSM hook for kernel module loading.
> >
> > Before enabling in-kernel module decompression, a kernel module in
> > initramfs can still be loaded with ima_policy=secure_boot. So adjust the
> > kernel module rule in secure_boot policy to allow either an IMA
> > signature OR an appended signature i.e. to use
> > "appraise func=MODULE_CHECK appraise_type=imasig|modsig".
> >
> > Reported-by: Karel Srot <ksrot@redhat.com>
> > Suggested-by: Mimi Zohar <zohar@linux.ibm.com>
> > Signed-off-by: Coiby Xu <coxu@redhat.com>
> > ---
> > v1: https://lore.kernel.org/linux-integrity/20250928030358.3873311-1-coxu@redhat.com/
> >
> > include/linux/lsm_hook_defs.h | 2 ++
> > include/linux/security.h | 7 +++++++
> > kernel/module/main.c | 10 +++++++++-
> > security/integrity/ima/ima_main.c | 26 ++++++++++++++++++++++++++
> > security/integrity/ima/ima_policy.c | 2 +-
> > security/security.c | 17 +++++++++++++++++
> > 6 files changed, 62 insertions(+), 2 deletions(-)
>
> We don't really need a new LSM hook for this do we? Can't we just
> define a new file read type, e.g. READING_MODULE_DECOMPRESS, and do
> another call to security_kernel_post_read_file() after the module is
> unpacked? Something like the snippet below ...
Yes, this is similar to my suggestion based on defining multiple enumerations:
READING_MODULE, READING_COMPRESSED_MODULE, and READING_DECOMPRESSED_MODULE.
With this solution, IMA would need to make an exception in the post kernel
module read for the READING_COMPRESSED_MODULE case, since the kernel module has
not yet been decompressed.
Coiby suggested further simplification by moving the call later. At which point
either there is or isn't an appended signature for non-compressed and
decompressed kernel modules.
As long as you don't have a problem calling the security_kernel_post_read_file()
hook again, could we move the call later and pass READING_MODULE_UNCOMPRESSED?
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index c66b26184936..f127000d2e0a 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3693,6 +3693,14 @@ static int init_module_from_file(struct file *f, const ch
> ar __user * uargs, int
> mod_stat_add_long(len, &invalid_decompress_bytes);
> return err;
> }
> +
> + err = security_kernel_post_read_file(f,
> + (char *)info.hdr, info.len,
> + READING_MODULE_DECOMPRESS);
> + if (err) {
> + mod_stat_inc(&failed_kreads);
> + return err;
> + }
> } else {
> info.hdr = buf;
> info.len = len;
== defer security_kernel_post_read_file() call to here ==
Mimi
next prev parent reply other threads:[~2025-11-02 15:06 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
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 [this message]
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=baa39fcd1b6b485f14b8f06dcd96b81359e6e491.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=coxu@redhat.com \
--cc=da.gomez@kernel.org \
--cc=dmitry.kasatkin@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-modules@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=paul@paul-moore.com \
--cc=petr.pavlu@suse.com \
--cc=roberto.sassu@huawei.com \
--cc=samitolvanen@google.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).