Message-ID: <27bb0c218084f51eba07f041d0fffea8971865b9.camel@linux.ibm.com>
Date: Fri, 17 Oct 2025 13:49:58 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Coiby Xu <coxu@...hat.com>
Cc: linux-integrity@...r.kernel.org,
        Dmitry Torokhov
 <dmitry.torokhov@...il.com>,
        Karel Srot <ksrot@...hat.com>,
        Roberto Sassu
 <roberto.sassu@...wei.com>,
        Dmitry Kasatkin	 <dmitry.kasatkin@...il.com>,
        Eric Snowberg <eric.snowberg@...cle.com>,
        Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn"	 <serge@...lyn.com>,
        "open list:SECURITY SUBSYSTEM"	 <linux-security-module@...r.kernel.org>,
        open list	 <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ima: Fall back to default kernel module signature
 verification

On Fri, 2025-10-17 at 11:19 +0800, Coiby Xu wrote:
> On Thu, Oct 16, 2025 at 10:31:35PM -0400, Mimi Zohar wrote:
> > On Thu, 2025-10-16 at 11:46 +0800, Coiby Xu wrote:
> > > On Tue, Sep 30, 2025 at 04:28:14PM -0400, Mimi Zohar wrote:
> > > > On Tue, 2025-09-30 at 09:57 -0400, Mimi Zohar wrote:
> > > > > On Sun, 2025-09-28 at 11:03 +0800, Coiby Xu wrote:
> > > > > > 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@...hat.com>
> > > > > > Signed-off-by: Coiby Xu <coxu@...hat.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.
> > > > > 
> > > > > Coiby, there are multiple issues being discussed here.  Before deciding on an
> > > > > appropriate solution, let's frame the issues(s) properly.
> > > 
> > > Hi Mimi,
> > > 
> > > Thanks for listing and framing the issues! Sorry, it took me a while to
> > > go through your feedback as I also had a 8-day holiday.
> > > 
> > > > > 
> > > > > 1. The finit_module syscall eventually calls init_module_from_file() to read the
> > > > > module into memory and then decompress it.  The problem is that the kernel
> > > > > module signature verification occurs during the kernel_read_file(), before the
> > > > > kernel module is decompressed.  Thus, the appended kernel module signature
> > > > > cannot be verified.
> > > 
> > > Since IMA only accesses a kernel module as a fd or struct file*, even if
> > > IMA hook is triggerd after kernel module is decompressed, IMA still
> > > doesn't know the default verification has passed or can't access the
> > > decompressed kernel buffer [2] to do the verification by itself.
> > > 
> > > [2] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/module/main.c?h=v6.17#n3689
> > > 
> > > > > 
> > > > > 2. CPIO doesn't have xattr support. There were multiple attempts at including
> > > > > xattrs in CPIO, but none were upstreamed [1].  If file signatures stored in
> > > > > security.ima were available in the initramfs, then finit_module() could verify
> > > > > them, as opposed to the appended kernel module signature.
> > > 
> > > Thanks you for pointing me to the work [1]. I'll take a more careful
> > > look at [1]. I think CPIO supporting xattr can be a long-term solution
> > > and also close a important security gap.
> > > 
> > > > > 
> > > > > 3. The issues described above are generic, not limited to Power.  When
> > > > > CONFIG_MODULE_SIG is configured, the arch specific IMA policy rules do not
> > > > > include an "appraise func=MODULE_CHECK".
> > > 
> > > Yes, the issue is not limited to Power. And thanks for correcting me
> > > that Power arch specific IMA policy rules don't have this problem! Sorry
> > > I misread the code.
> > > 
> > > > > 
> > > > > 4. Unlike the arch specific IMA policy rules, the built-in secure boot IMA
> > > > > policy, specified on the boot command line as "ima_policy=secure_boot", always
> > > > > enforces the IMA signature stored in security.ima.
> > > > > 
> > > > > Partial solutions without kernel changes:
> > > > > - Enable CONFIG_MODULE_SIG  (Doesn't solve 4)
> > > > > - Disable kernel module compression.
> > > > > 
> > > > > Complete solution:
> > > > > - Pick up and upstream Roberto Sassu's last version of initramfs support [1].
> > > > > - Somehow prevent kernel_read_file() from failing when the kernel_read_file_id
> > > > > enumeration is READING_MODULE and the kernel module is compressed.  The change
> > > > > might be limited to ima_post_read_file().
> > > > 
> > > > or perhaps not totally.
> > > > 
> > > > init_module_from_file() doesn't pass the flags variable to kernel_read_file().
> > > > You might want to consider defining a new kernel_read_file_id enumeration named
> > > > READING_COMPRESSED_MODULE.
> > > 
> > > Thanks for suggesting the solutions! I like the solution of CPIO
> > > supporting xattr but it seems it won't land in upstream soon. So I
> > > prefer the last approach. I've implemented one [3] by defining a new
> > > kernel_read_file_id enumeration, would you like me to post the patches
> > > to the mailing list directly?
> > > 
> > > [3] https://github.com/coiby/linux/tree/in_kernel_decompression_ima
> > 
> > A few thoughts, before you post the patch.
> 
> Thank you for sharing your thoughts!
> 
> > 
> > 1. In the general case, the kernel module could be compressed, but without an
> > appended signature.  The new code should only defer appended signature
> > verification, if there isn't an xattr or appended signature.
> 
> I'll add these two condition checks, thanks!
> 
> > 
> > 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.

> 
> > 
> > 3.  The patch title "ima: Use default kernel module signature verification for
> > compressed ones" is a bit off.  It should be something along the lines of "ima:
> > defer compressed kernel module appended signature verification".
> 
> > 
> > 4. Simplify the patch description.
> 
> I'll rephrase the title and try simplifying it. Thanks!

Thank you.

Powered by blists - more mailing lists