linux-kernel - Re: [PATCH] ima: Fall back to default kernel module signature verification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bcd1f7b48311aff55711cdff4a6cdbb72aae1d04.camel@linux.ibm.com>
Date: Tue, 30 Sep 2025 16:28:14 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Coiby Xu <coxu@...hat.com>, linux-integrity@...r.kernel.org
Cc: 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 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.
> 
> 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.
> 
> 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.
> 
> 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".
> 
> 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.

Mimi

> 
> [1] [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk
> https://lore.kernel.org/linux-fsdevel/20190523121803.21638-1-roberto.sassu@huawei.com/
> 
>