[RFC PATCH] ima: add a knob to make IMA be able to be disabled

[Coiby Xu]

On Tue, Apr 29, 2025 at 07:39:17AM -0400, Mimi Zohar wrote:
>On Mon, 2025-04-28 at 11:48 +0800, Coiby Xu wrote:
>> On Wed, Apr 16, 2025 at 11:22:52AM +0800, Baoquan He wrote:
>> > On 04/09/25 at 11:40am, Mimi Zohar wrote:
>> > > On Wed, 2025-04-09 at 10:42 +0800, Baoquan He wrote:
>> > ......snip..
>> > > > Thanks for confirming. I will consider how to fix it accordingly. Maybe
>> > > > after Steven's patches are merged. That would be great if the buffer
>> > > > allocating and storing can be skiped for kdump in Steven's patch. While
>> > > > I am worried that could disrupt the progress of Steven's patches.
>> > >
>> > > Agreed, let's get Steven's patch set upstreamed and then make the kdump
>> > > exceptions.
>> > >
>> > > - "ima: kexec: move IMA log copy from kexec load to execute" looks like it
>> > > isn't
>> > > copying the IMA measurement list records (kexec_post_load), but the memory for
>> > > the IMA measurement list is being allocated (ima_alloc_kexec_file_buf).
>> > >
>> > > - Do you really want to totally disable IMA for kdump or would disabling IMA-
>> > > measurement be sufficient?  Remember there's already an option to disable IMA-
>> > > appraisal.  Disabling just IMA-measurement would allow IMA-appraisal to
>> > > continue
>> > > to work.  Meaning based on policy the integrity of files - executables, kernel
>> > > image, etc - could still be verified.
>> > >
>> > > Without IMA-measurement:
>> > > - No adding records to the IMA measurement list
>> > > - No IMA measurement list pseudo securityfs files
>> > > - No extending the TPM
>> > >
>> > > With IMA-appraisal:
>> > > - Integrity verification of files based on keys, keyrings
>> > > - Loading keys
>>
>> Thanks for listing the impacts of disabling IMA measurement or
>> appraisal!
>>
>> kdump builds and loads its own initramfs as a cpio archive. After a
>> kernel crashes, the loaded initramfs will save the crashed kernel's
>> memory (vmcore) to specified location and then it will reboot the system
>> immediately. Since kdump merely copy files from existing fs into its
>> initramfs, I think at least majority of users don't need IMA for kdump.
>
>That's fine.
>
>> In fact, currently IMA-appraisal doesn't work for kdump because cpio
>> doesn't support xattr.
>
>Although CPIO doesn't support xattrs, tmpfs supports xattrs.

Thanks for pointing it out! I thought tmpfs doesn't support xattrs
because ima_policy=tcb excludes TMPFS_MAGIC. There are still many
interesting questions for me to explore. For example, I don't understand
how 1st kernel's initramfs is shown as ramfs (which doesn't support
xattrs) but kdump intiramfs without the squashfs module is shown as
tmpfs.

>I'm aware that some
>store the security xattr information in a file and write it out as xattrs.

If the built initramfs as a CPIO file doesn't carry xattrs, the loaded
initramfs still doesn't have xattrs. I just found the initramfs could
opt to use squashfs or erofs which supports xattrs but currently it's
hardcoded to disable xattrs. For example, recently the dracut erorfs
module also follows squashfs to disable xattrs [1]. So in the near
future, I don't expect xattrs to be supported in kdump.

[1] https://github.com/dracut-ng/dracut-ng/pull

>
>> As for the issue of not properly updating the
>> security xattrs, I think in most of cases disabling IMA-appraisal in
>> kdump won't cause the trouble. If the vmcore is saved to a remote fs, the
>> local fs won't even be touched. If the vmcore is saved to local fs and
>> the appraisal rules cover the saved vmcore and the created logs files,
>> we only need to update the xattr file of three files. So from the
>> perspective of kdump, it's good to disable IMA for kdump to save memory.
>
>Remember my original concerns weren't about disabling IMA for kdump, but about not
>limiting disabling IMA to just kdump.

Thanks for reminding me about that! Baoquan will post a patch to only
disable IMA for kdump so we won't need to worry about these concerns:)

>
>> Of course we can't rule out the possibility some users may want to need
>> IMA in kdump. So a flexible solution like providing a knob to allow
>> users to enable IMA in kdump will be the ideal solution.
>
>Agreed
>
>>
>> Btw, recently, a colleague reminds me of an issue that the system hangs
>> because systemd fails to load incorrect /etc/ima/ima-policy. Of course,
>> we should ask users to verify the policy beforehand. But it's still
>> possible the booting process may be stopped by a strict, albeit
>> syntax-correct policy and users can't log into the system to fix the
>> policy. Do you think a knob to disable IMA is needed to address these
>> cases or is there a better solution?
>
>Agreed a new policy should always be tested, before attempting to load it on boot.
>However there are situations when even a tested policy fails.  Commonly this occurs
>when attempting to load an IMA policy based on IMA features that don't exist in an
>older kernel.  This can normally be resolved by booting into the newer kernel and
>"fixing" the policy.  Instead of disabling IMA, I would allow specifying on the boot
>command line an alternate IMA policy (e.g. ima-policy.backup-version) to be loaded
>as fallback.

Thanks for letting me know the case where an IMA policy may fails
because of an older kernel. I'll start a new thread to discuss how to
fix an booting failure issue since it can be decoupled from this patch.
Previously you reminded me that re-enabling IMA will require re-fixing
security.ima. Then I realize that changing IMA policy will also require
such re-fixing otherwise booting failure may also occur if it involves a
critical component. So I'll also ask your advice for this matter in the
new thread as well.

-- 
Best regards,
Coiby