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

[Coiby Xu]

On Fri, May 09, 2025 at 09:03:11AM -0400, Mimi Zohar wrote:
>[Cc'ing Roberto]
>
>On Fri, 2025-05-09 at 13:59 +0800, Coiby Xu wrote:
>> 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.
>
>Try adding "rootfstype=tmpfs" to the boot command line.  For a detailed explanation,
>take a look at commit 21528c69a0d8 ("rootfs: Fix support for rootfstype= when root=
>is given").

Thanks for pointing me to the above commit! I'll check it.

>
>>
>> > 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

Sorry, I didn't notice the link is incomplete. It should be

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

>
>Right, so the issue isn't the initramfs root filesystem, but CPIO.  Either CPIO
>would need to be extended, which multiple people have attempted to do, or the xattrs
>could be stored in a file and written out to the initramfs root filesystem.  In fact
>Roberto's last attempts at adding CPIO xattr support did something like that.
>
>https://lore.kernel.org/linux-integrity/20190523121803.21638-1-roberto.sassu@huawei.com/

Thanks for introducing Roberto's work to me!

>
>Mimi
>

-- 
Best regards,
Coiby