On Mon, 2025-10-20 at 14:45 +0200, Roberto Sassu wrote: > 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.
Thank you!
