Re: [PATCH] kexec_file: ima: allow loading a kernel with its IMA signature verified

[Coiby Xu]

On Thu, Jul 13, 2023 at 05:59:38PM +0000, Eric Snowberg wrote:
> > On Jul 12, 2023, at 12:31 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote:
> >
> > [Cc'ing the LSM mailing list.]
> >
> > On Tue, 2023-07-11 at 11:16 +0800, Coiby Xu wrote:
> > > When IMA has verified the signature of the kernel image, kexec'ing this
> > > kernel should be allowed.
> > >
> > > Fixes: af16df54b89d ("ima: force signature verification when CONFIG_KEXEC_SIG is configured")
> > > Signed-off-by: Coiby Xu <coxu@xxxxxxxxxx>
> >
> > The original commit  29d3c1c8dfe7 ("kexec: Allow kexec_file() with
> > appropriate IMA policy when locked down") was not in lieu of the PE-
> > COFF signature, but allowed using the IMA signature on other
> > architectures.
> >
> > Currently on systems with both PE-COFF and IMA signatures, both
> > signatures are verified, assuming the file is in the IMA policy.  If
> > either signature verification fails, the kexec fails.
> >
> > With this patch, only the IMA signature would be verified.
> >
> > > ---
> > > kernel/kexec_file.c | 14 +++++++++-----
> > > 1 file changed, 9 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> > > index 881ba0d1714c..96fce001fbc0 100644
> > > --- a/kernel/kexec_file.c
> > > +++ b/kernel/kexec_file.c
> > > @@ -162,6 +162,13 @@ kimage_validate_signature(struct kimage *image)
> > > 	ret = kexec_image_verify_sig(image, image->kernel_buf,
> > > 				     image->kernel_buf_len);
> > > 	if (ret) {
> > > +		/*
> > > +		 * If the kernel image already has its IMA signature verified, permit it.
> > > +		 */
> > > +		if (ima_appraise_signature(READING_KEXEC_IMAGE)) {
> > > +			pr_notice("The kernel image already has its IMA signature verified.\n");
> > > +			return 0;
> > > +		}
>
> The issue I see here is ret could be many things, for example it could be
> -EKEYREJECTED, meaning it was contained on a revocation list.  With this patch
> the revocation could be overruled if the image was IMA signed with a different
> key.  Do we really want to add the ability to overrule a revocation?

Thanks for raising the concern! I haven't thought about this case of the
key being in a revocation list. If the IMA signature comes from a
distribution, the distribution should also blocklist the IMA key when
the PE-COFF signature key is added to the revocation list. If the IMA
signature is from an end-user, I think the user wants to pass the
verification in this case.

Or how about only allowing IMA signature when EFI runtime services are
disabled?  Another reason I am yet to add to the commit message is a
real-time kernel currently disables EFI runtime services for latency
issues so it can't access the MOK keys to verify the PECOFF signature.