linux-kernel - Re: [PATCH] ima: add a knob ima= to make IMA be able to be disabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAF+s44TOjC60hfTU2JKQrfiogUin5E=O7XvePb86Lv7jjobJ1Q@mail.gmail.com>
Date: Fri, 30 May 2025 12:14:57 +0800
From: Pingfan Liu <piliu@...hat.com>
To: Mimi Zohar <zohar@...ux.ibm.com>
Cc: Baoquan He <bhe@...hat.com>, prudo@...hat.com, linux-integrity@...r.kernel.org, 
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	pmenzel@...gen.mpg.de, coxu@...hat.com, ruyang@...hat.com, 
	chenste@...ux.microsoft.com
Subject: Re: [PATCH] ima: add a knob ima= to make IMA be able to be disabled

On Thu, May 29, 2025 at 10:32 PM Mimi Zohar <zohar@...ux.ibm.com> wrote:
>
> On Thu, 2025-05-29 at 12:13 +0800, Pingfan Liu wrote:
> > On Tue, May 27, 2025 at 10:18 PM Mimi Zohar <zohar@...ux.ibm.com> wrote:
> > >
> > > On Tue, 2025-05-27 at 11:25 +0800, Pingfan Liu wrote
> > > > > >
> > > > > >
> > > > > > We're trying to close integrity gaps, not add new ones.  Verifying the
> > > > > > UKI's
> > > > > > signature addresses the integrity of the initramfs.  What about the
> > > > > > integrity of
> > > > > > the kdump initramfs (or for that matter the kexec initramfs)?  If the
> > > > > > kdump
> > > > > > initramfs was signed, IMA would be able to verify it before the kexec.
> > > >
> > > > IMHO, from the higher level, if there is a requirement on the integrity of
> > > > the
> > > > initramfs, it should take a similar approach as UKI. And the system admin
> > > > can
> > > > choose whether to disable the unsafe format loader or not.
> > >
> > > Yes, that is a possibility, probably a good aim, but in the case of
> > > kexec/kdump
> > > that isn't really necessary.  As filesystem(s) support xattrs, IMA policies
> > > could be written in terms of "func=KEXEC_INITRAMFS_CHECK" to include the
> > > initramfs.
> > >
> >
> > Just aware that we have such a cool feature. Thanks!
>
> > I checked the code. IIUC, the relevant code has already been in the
> > kernel. And the thing left to do is to install an IMA policy, right?
>
> Correct.  The problem up to now has been that the initramfs was created on the
> fly on the target system, so it was impossible to remotely sign it by the
> distro.
>
> >
> > But there are still two things to be considered.
> > -1.The UEFI partition is FAT format, which can not support xattr
>
> The normal kexec/kdump kernel image and initramfs are stored in /boot, not the
> UEFI partition.  Is that changing?
>
I think that is the case if grub is used as a bootloader.

But officially, only FAT32 is supported in the UEFI specification. So
if a UEFI application (let's say systemd-boot) tries to load kernel
and initramfs, then boots into kernel, it can only expect to read
these files from FAT32 partition.

> e.g. kexec -s -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -
> r`.img --reuse-cmdline
>
> > -2. Just like in the UKI case, the kernel fd content is not necessary
> > for the kernel image itself. The initramfs fd can be used to pass some
> > extra data if we use a temp file as a package. So checking the
> > signatures at the initramfs level will block this usage
>
> Sorry I lost you here.  What exactly is included in the UKI signature?  What is
> this initramfs fd extra data?  Is it included in the UKI signature?  Can you
> point me to some documentation?
>

Sorry for the awkward expression, let me clarify it.

It is a pity that these things are on the fly and there are no documents yet.

With the advent of UKI, which encapsulates the kernel, initramfs, and
cmdline into a single PE file, the original kexec_file_load syscall
schema no longer aligns with this design.

SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
                unsigned long, cmdline_len, const char __user *, cmdline_ptr,
                unsigned long, flags)

In particular, the kernel_fd parameter no longer refers to just the
kernel image alone.
And the same thing may happen to initrd_fd.

In essence, it means the redesign or re-explaining of the
kexec_file_load() interface, but for the time being, these things are
on the fly.

Thanks,

Pingfan