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.
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
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.
Thanks for reminding me about that! Baoquan will post a patch to only
disable IMA for kdump so we won't need to worry about these concerns:)
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.
Thanks for letting me know the case where an IMA policy may fails
because of an older kernel. I'll start a new thread to discuss how to
fix an booting failure issue since it can be decoupled from this patch.
Previously you reminded me that re-enabling IMA will require re-fixing
security.ima. Then I realize that changing IMA policy will also require
such re-fixing otherwise booting failure may also occur if it involves a
critical component. So I'll also ask your advice for this matter in the
new thread as well.
--
Best regards,
Coiby
