On Thu, Oct 30, 2025 at 12:50:48PM -0400, Mimi Zohar wrote:
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.
Thanks for the confirmation! v2 has been posted.
Mimi
--
Best regards,
Coiby
