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: <aC86NSypHlER2C3L@MiWiFi-R3L-srv>
Date: Thu, 22 May 2025 22:52:37 +0800
From: Baoquan He <bhe@...hat.com>
To: Mimi Zohar <zohar@...ux.ibm.com>, piliu@...hat.com, prudo@...hat.com
Cc: 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 05/22/25 at 07:08am, Mimi Zohar wrote:
> On Thu, 2025-05-22 at 11:24 +0800, Baoquan He wrote:
> > On 05/21/25 at 08:54am, Mimi Zohar wrote:
> > > On Fri, 2025-05-16 at 08:22 +0800, Baoquan He wrote:
> > > > CC kexec list.
> > > > 
> > > > On 05/16/25 at 07:39am, Baoquan He wrote:
> > > > > Kdump kernel doesn't need IMA functionality, and enabling IMA will cost
> > > > > extra memory. It would be very helpful to allow IMA to be disabled for
> > > > > kdump kernel.
> > 
> > Thanks a lot for careufl reviewing and great suggestions.
> > 
> > > 
> > > The real question is not whether kdump needs "IMA", but whether not enabling
> > > IMA in the kdump kernel could be abused.  The comments below don't address
> > > that question but limit/emphasize, as much as possible, turning IMA off is
> > > limited to the kdump kernel.
> > 
> > Are you suggesting removing below paragraph from patch log because they
> > are redundant? I can remove it in v2 if yes.
> 
> "The comments below" was referring to my comments on the patch, not the next
> paragraph.  "don't address that question" refers to whether the kdump kernel
> could be abused.
> 
> 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.

Kdump initramfs could be generated each time when loading once change is
detected, e.g newer kernel, kdump config tuning. It's different than
UNI's normal initramfs. We don't need verify it as far as I know
according to discussion with UNI dev, so ima=off can be set by default
in kdump kernel. Even though one day that's really needed, ima=on|off is
a switch, not a hard code.

Add people woiking on kdump UKI to CC.

> 
> As for the next paragraph, based on Coiby's response, please remove it.

Got it, thanks.