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

[Mimi Zohar]

[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").

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

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/

Mimi