On Thu, 2025-10-30 at 21:42 +0800, Coiby Xu wrote: > > > > > > Another question is whether we should allow loading a kernel module with > > > appended signature but misses IMA signature. Both IMA arch specific policy > > > and init_module syscall only require appended signature verification. On > > > the other hand, we only allow "appraise_type=imasig|modsig" but not > > > appraise_type=modsig. How about we allow loading a kernel module with > > > valid appended signature regardless of its IMA signature? We won't call > > > set_module_sig_enforced but as long as we know is_module_sig_enforced() > > > is true, we allow the module in IMA. > > > > Based on the policy, IMA enforces signature verification. Only if > > CONFIG_MODULE_SIG is configured, the IMA arch specific policy does not > > define an > > IMA kernel module appraise rule. However, custom policies could still > > require > > both types of signatures, not necessarily signed by the same entity. > > > > The option "appraise_type=imasig|modsig" allows either an IMA signature OR > > an > > appended signature. > > Thanks for the clarification! If I understand you correctly, some users > may want to enforce IMA signature verification and we should provide > such flexibility. Then do you think it's a good idea to change the kernel > module rule in ima_policy=secure_boot to > "appraise func=MODULE_CHECK appraise_type=imasig|modsig" so > ima_policy=secure_boot can also work for in-kernel decompressing > modules?
Yes, that's fine. Unlike the arch specific policy rules and the Kconfig appraise rules, which persist after loading a custom policy, the builtin secure boot rules do not persist. Mimi
