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

[Roberto Sassu]

On Mon, 2025-10-20 at 08:21 -0400, Mimi Zohar wrote:
> 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?

I haven't had time to look at it recently. I can take the openEuler
version, address the remaining comments and repost.

Roberto