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 for Android: free password hash cracker in your pocket

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

Message-ID: <hn455nyrp65bb23ltub4tet6ixfcggshgerxm2bhun4ubv2iau@eanh3ka67irf>
Date: Wed, 4 Jun 2025 11:34:34 +0800
From: Coiby Xu <coxu@...hat.com>
To: Mimi Zohar <zohar@...ux.ibm.com>
Cc: Baoquan He <bhe@...hat.com>, linux-integrity@...r.kernel.org, 
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org, pmenzel@...gen.mpg.de, 
	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 22, 2025 at 07:08:04AM -0400, 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.

Hi Mimi,

I thought you were asking that the commit message should address the
question why disabling IMA should be limited to the kdump kernel. It
turns out I misunderstood your concern.

Currently there is no way provided to verify the kdump initramfs as a
whole file or to verify individual files in the kdump initramfs.

As you have already known, the kdump initramfs is always generated on
the fly and will be re-generated when the dumping target changes or
some important files change. We try to generate a minimal initramfs in
order to save memory. So yes, it's impossible to sign it as a whole file
beforehand. 

And since xattrs like security.ima are not supported in the kdump
initramfs, we have no way to use IMA to verify individual file's
integrity.  In fact, we have to stop IMA from working otherwise it's
very likely kdump will break.

So far, I'm not aware of any bug report that complains kdump stops
working because of IMA. So it indicates very few users are trying to use
IMA in kdump.

If users do have concerns on the integrity of kdump initramfs, I think
we can advice users to make sure the deployed IMA policy will verify the
integrity of the files while they are being collected and copied into
the kdump initramfs by tools like dracut.

-- 
Best regards,
Coiby