Re: [PATCH v5 2/6] powerpc/kexec_file: Add KEXEC_SIG support.

Michal Suchánek
2022-02-14T15:55:34Z

Hello,

On Mon, Feb 14, 2022 at 10:14:16AM -0500, Mimi Zohar wrote:
> Hi Michal,
>
> On Sun, 2022-02-13 at 21:59 -0500, Mimi Zohar wrote:
>
> >
> > On Tue, 2022-01-11 at 12:37 +0100, Michal Suchanek wrote:
> > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > > index dea74d7717c0..1cde9b6c5987 100644
> > > --- a/arch/powerpc/Kconfig
> > > +++ b/arch/powerpc/Kconfig
> > > @@ -560,6 +560,22 @@ config KEXEC_FILE
> > > config ARCH_HAS_KEXEC_PURGATORY
> > > def_bool KEXEC_FILE
> > >
> > > +config KEXEC_SIG
> > > + bool "Verify kernel signature during kexec_file_load() syscall"
> > > + depends on KEXEC_FILE && MODULE_SIG_FORMAT
> > > + help
> > > + This option makes kernel signature verification mandatory for

This is actually wrong. KEXEC_SIG makes it mandatory that any signature
that is appended is valid and made by a key that is part of the platform
keyiring (which is also wrong, built-in keys should be also accepted).
KEXEC_SIG_FORCE or an IMA policy makes it mandatory that the signature
is present.

> > > + the kexec_file_load() syscall.
> >
> > When KEXEC_SIG is enabled on other architectures, IMA does not define a
> > kexec 'appraise' policy rule. Refer to the policy rules in
> > security/ima/ima_efi.c. Similarly the kexec 'appraise' policy rule in

I suppose you mean security/integrity/ima/ima_efi.c

I also think it's misguided because KEXEC_SIG in itself does not enforce
the signature. KEXEC_SIG_FORCE does.

> > arch/powerpc/kernel/ima_policy.c should not be defined.

I suppose you mean arch/powerpc/kernel/ima_arch.c - see above.

Thanks for taking the time to reseach and summarize the differences.

> The discussion shouldn't only be about IMA vs. KEXEC_SIG kernel image
> signature verification. Let's try and reframe the problem a bit.
>
> 1. Unify and simply the existing kexec signature verification so
> verifying the KEXEC kernel image signature works irrespective of
> signature type - PE, appended signature.
>
> solution: enable KEXEC_SIG (This patch set, with the above powerpc IMA
> policy changes.)
>
> 2. Measure and include the kexec kernel image in a log for attestation,
> if desired.
>
> solution: enable IMA_ARCH_POLICY
> - Powerpc: requires trusted boot to be enabled.
> - EFI: requires secure boot to be enabled. The IMA efi policy
> doesn't differentiate between secure and trusted boot.
>
> 3. Carry the kexec kernel image measurement across kexec, if desired
> and supported on the architecture.
>
> solution: enable IMA_KEXEC
>
> Comparison:
> - Are there any differences between IMA vs. KEXEC_SIG measuring the
> kexec kernel image?
>
> One of the main differences is "what" is included in the measurement
> list differs. In both cases, the 'd-ng' field of the IMA measurement
> list template (e.g. ima-ng, ima-sig, ima-modsig) is the full file hash
> including the appended signature. With IMA and the 'ima-modsig'
> template, an additional hash without the appended signature is defined,
> as well as including the appended signature in the 'sig' field.
>
> Including the file hash and appended signature in the measurement list
> allows an attestation server, for example, to verify the appended
> signature without having to know the file hash without the signature.

I don't understand this part. Isn't the hash *with* signature always
included, and the distinguishing part about IMA is the hash *without*
signature which is the same irrespective of signature type (PE, appended
xattr) and irrespective of the keyt used for signoing?

> Other differences are already included in the Kconfig KEXEC_SIG "Notes"
> section.

Which besides what is already described above would be blacklisting
specific binaries, which is much more effective if you have hashes of
binaries without signature.

Thanks

Michal