Message-ID: <20220214155524.GN3113@kunlun.suse.cz>
Date:   Mon, 14 Feb 2022 16:55:24 +0100
From:   Michal Suchánek <msuchanek@...e.de>
To:     Mimi Zohar <zohar@...ux.ibm.com>
Cc:     keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-integrity@...r.kernel.org, kexec@...ts.infradead.org,
        Philipp Rudo <prudo@...hat.com>,
        Nayna <nayna@...ux.vnet.ibm.com>, Rob Herring <robh@...nel.org>,
        linux-s390@...r.kernel.org, Vasily Gorbik <gor@...ux.ibm.com>,
        Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Jessica Yu <jeyu@...nel.org>, linux-kernel@...r.kernel.org,
        David Howells <dhowells@...hat.com>,
        Christian Borntraeger <borntraeger@...ibm.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Paul Mackerras <paulus@...ba.org>,
        Hari Bathini <hbathini@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        linuxppc-dev@...ts.ozlabs.org,
        Frank van der Linden <fllinden@...zon.com>,
        Thiago Jung Bauermann <bauerman@...ux.ibm.com>,
        Daniel Axtens <dja@...ens.net>, buendgen@...ibm.com,
        Michael Ellerman <mpe@...erman.id.au>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Dmitry Kasatkin <dmitry.kasatkin@...il.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Baoquan He <bhe@...hat.com>,
        linux-security-module@...r.kernel.org
Subject: Re: [PATCH v5 2/6] powerpc/kexec_file: Add KEXEC_SIG support.

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

Powered by blists - more mailing lists