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

[Mimi Zohar]

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.  I'm aware that some
store the security xattr information in a file and write it out as xattrs.

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

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

> 
> > 
> > Currently, Kdump has no demand to do integrity verification based on
> > keys, keyrings, except of Coiby's LUKS support in kdump:
> > 
> > [PATCH v8 0/7] Support kdump with LUKS encryption by reusing LUKS volume keys
> > https://lore.kernel.org/all/20250207080818.129165-1-coxu@redhat.com/T/#u
> > 
> > I have talked to Coiby, he will do some investigations to see if loading
> > keys related to IMA or IMA-appraisal functionality is related to LUKS
> > support in kdump because the LUKS support in kdump also needs
> > store/restore keys/keyrings between normal kernel and kdump kernel.
> 
> Thanks for reminding me about kdump LUKS support. IMA will create
> keyring like .ima for loading keys and other components can still create
> their own keyrings or use existing keyrings. And I can confirm kdump
> LUKS support won't be affected. 

thanks,

Mimi