On Wed, Oct 29, 2025 at 11:01:27PM -0400, Mimi Zohar wrote:
On Thu, 2025-10-30 at 08:31 +0800, Coiby Xu wrote:
On Fri, Oct 24, 2025 at 11:16:37AM -0400, Mimi Zohar 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().
>
> Looking at the code further, decompressing the kernel module in IMA is
> redundant. Instead I think the best approach would be to:
> - define DECOMPRESSED_MODULE, in addition to COMPRESSED_MODULE.
>
> id(COMPRESSED_MODULE, compressed-kernel-module) \
> id(DECOMPRESSED_MODULE, decompressed-kernel-module) \
>
> - instead of passing a boolean indicating whether the module is compressed,
pass
> the kernel_read_file_id enumeration to differentiate between the compressed
and
> decompressed module.
>
> - define a new IMA hook, probably LSM hook as well, named
> ima_decompressed_module().
>
> - call the new ima_decompressed_module() from init_module_from_file()
> immediately after decompressing the kernel module. Something along the lines
> of:
>
> err = ima_decompressed_module(f, (char *)info.hdr, info.len,
> READING_DECOMPRESSED_MODULE);
Thanks for proposing a better solution! Yeah, decompressing the kernel
module in IMA is unnecessary. Do you think we can further extend your
idea to call one IMA hook only after kernel module decompression is
done? If we call two IMA hooks in finit_module, we'll need coordination
between two IMA hooks i.e. the 1st IMA hook shouldn't fail in order for
the 2nd IMA hook to be executed. The new IMA hook will always have
access to the decompressed kernel module buffer so there is no need to
differentiate between compressed and decompressed module.
Agreed instead of verifying the kernel module signature on the LSM
kernel_post_read_file() hook, define and move it to a new IMA/LSM hook after it
is decompressed, would be much simpler than coordinating two LSM hooks.
Thanks for confirming it! I'll send a new version once the testing is
finished.
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?
--
Best regards,
Coiby
