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

[Mimi Zohar]

On Wed, 2025-04-09 at 10:42 +0800, Baoquan He wrote:
> On 04/07/25 at 07:46am, Mimi Zohar wrote:
> > On Mon, 2025-04-07 at 09:34 +0800, Baoquan He wrote:
> > > On 04/03/25 at 04:03pm, Mimi Zohar wrote:
> > > > On Wed, 2025-04-02 at 19:49 +0800, Baoquan He wrote:
> > > > > On 04/02/25 at 04:43pm, Coiby Xu wrote:
> > > > > > On Tue, Apr 01, 2025 at 11:30:09PM -0400, Mimi Zohar wrote:
> > > > > > > On Wed, 2025-04-02 at 09:47 +0800, RuiRui Yang wrote:
> > > > > > [...]
> > > > > > > > > > that.  Please don't make it generic like this.
> > > > > > > > > > 
> > > > > > > > > > Please refer to ima_appraise_parse_cmdline().
> > > > > > > > > 
> > > > > > > > > Hi Mimi,
> > > > > > > > > 
> > > > > > > > > To save memory for kdump, it seems init_ima has been to be skipped thus
> > > > > > > > > ima=off is necessary (ima_appraise=off won't serve the purpose). Or do
> > > > > > > > > you have any specific concerns in mind?
> > > > > > > > 
> > > > > > > > I think as Mimi said see below logic enforces the IMA even with the
> > > > > > > > cmdline disabling, see ima_appraise_parse_cmdline:
> > > > > > > > if (sb_state) {
> > > > > > > >                 if (!(appraisal_state & IMA_APPRAISE_ENFORCE))
> > > > > > > >                         pr_info("Secure boot enabled: ignoring
> > > > > > > > ima_appraise=%s option",
> > > > > > > >                                 str);
> > > > > > > >         } else {
> > > > > > > >                 ima_appraise = appraisal_state;
> > > > > > > >         }
> > > > > > 
> > > > > > Thanks for pointing me to the above code! Note with the whole IMA
> > > > > > disabled as done by this patch, the above code will not run so IMA
> > > > > > (appraisal) won't be enforced.
> > > > > > 
> > > > > > > 
> > > > > > > Thanks, RuiRui.
> > > > > > > 
> > > > > > 
> > > > > > Mimi, so do I understand it correctly that your want IMA-appraisal to be
> > > > > > always enabled as long as secure boot is enabled even if users choose to
> > > > > > disable IMA? 
> > > > 
> > > > Secure boot is not the only reason.  Based on policy IMA-appraisal and EVM
> > > > calculate and store file hashes and HMAC's in their respective security xattrs.
> > > > Normally the usage of file hashes and HMAC's is limited to mutable files. 
> > > > Disabling IMA-appraisal could result in not properly updating the security
> > > > xattrs, which would result in not being able to verify the file's integrity on
> > > > reboot.
> > > > 
> > > > On systems where the RPM includes file signatures, file signatures of immutable
> > > > files can be safely restored.  Although it is possible to walk the filesystem(s)
> > > > "fixing" the xattrs of mutable files, it defeats the purpose.  "fix" mode should
> > > > only be enabled in a trusted environment.
> > > > 
> > > > > > I wonder what security issue will it bring if this promise
> > > > > > gets broken considering other LSMs can SELinux can be disabled when
> > > > > > secure boot is enabled?
> > > > 
> > > > The builtin IMA policy rules are not defined in terms of SELinux labels.  If the
> > > > initial IMA custom policy defines rules based on SELinux labels and SELinux is
> > > > not enabled, the policy will fail to be loaded.
> > > > 
> > > > > > > Coiby, would disabling just IMA-measurement, as opposed to IMA-appraisal, save
> > > > > > > sufficient memory for kdump?
> > > > > > 
> > > > > > For disabling just IMA-measurement, do you mean not enabling any measure
> > > > > > rules?  The more memory reserved for the kdump kernel, the less memory
> > > > > > can be used by the 1st kernel. So from the perfective of kdump, we try
> > > > > > to make the memory footprint as smaller as possible.
> > > > 
> > > > Got it.
> > > > 
> > > > > > Baoquan, do you have any statistics about the memory overhead of IMA?
> > > > > 
> > > > > I am getting a system to check that. I think there are two aspects of
> > > > > IMA functionality we want to disable. One is disable the IMA-measurement
> > > > > copying from 1st kernel to 2nd kernel, this is only needed by kexec
> > > > > reboot; the other is IMA is not needed at all in kdump kernel, means we
> > > > > don't want to call ima_init() to initialize
> > > > > ima_keyring/crypto/template/digests/fs etc. 
> > > > > 
> > > > > With my shallow knowledge about IMA, I don't know how to imitate
> > > > > appraisal cmdline to disable IMA partially in kdump kernel case.
> > > 
> > > Thanks for detailed explanations. Just back from holiday, sorry for late
> > > reply.
> > > 
> > > > 
> > > > The IMA policy controls how much or how little IMA measures and appraises.  Most
> > > > of the memory usage is the IMA measurement list, itself, and the per file cache
> > > > info.  (The per file cache info limits re-measuring or re-appraising files.)
> > > 
> > > In Steve Chen's kexec supporting ima patchset, kdump kernel loading
> > > should skip ima_kexec buffers allocating and storing via checking if
> > > (image->type == KEXEC_TYPE_CRASH).
> > > > 
> > > > Similarly my knowledge of kdump is very limited.  Is there a way for the kernel
> > > > to differentiate between kexec and kdump?  If we need a mechanism to disable
> > > > IMA-measurement, I'd *really* prefer it be limited to kdump.
> > > 
> > > Yes, function is_kdump_kernel() is provided for checking if the current
> > > kernel is in kdump kernel.
> > > 
> > > As said in earlier reply, for kdump kernel, there are two things we
> > > should do:
> > > 1) when loading 2nd kernel to prepare for switching, we should not
> > > allocate buffer and store IMA measurement list;
> > > 2) when switched into kdump kernel, we should not call ima_init() to do
> > > kinds of init which is useless.
> > > 
> > > My personnal opinion.
> > 
> > Thanks for pointing out the KEXEC_TYPE_CRASH check and is_kdump_kernel().  Both
> > changes sound reasonable.
> 
> 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

Obviously my preference would be to add support to disable IMA-measurement in a
kdump environment.

thanks,

Mimi