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.
In fact, currently IMA-appraisal doesn't work for kdump because cpio
doesn't support xattr. 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.
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.
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?
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-c...@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.
--
Best regards,
Coiby
