Message-ID: <bf593f8bcadc41e0c4823b7173ee5695da51152e.camel@linux.ibm.com>
Date: Wed, 04 Jun 2025 18:53:07 -0400
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Coiby Xu <coxu@...hat.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 Wed, 2025-06-04 at 11:34 +0800, Coiby Xu wrote:
> 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.

There were multiple attempts to close this integrity gap, but none of them were
upstreamed.
> 
> 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.

I'm just curious as to how UKI includes the initramfs, if it does, in the
signature.

> 
> 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.

For now, I'd prefer to leave it as an integrity gap that still needs to be
addressed.

thanks,

Mimi

Powered by blists - more mailing lists