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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <559f6ebf4a19da321fffc2a3ca180dc3d6216a22.camel@linux.ibm.com>
Date: Mon, 20 Oct 2025 08:21:49 -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 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



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ