Date:   Fri, 21 Jan 2022 16:50:52 +0000
From:   Roberto Sassu <roberto.sassu@...wei.com>
To:     Roberto Sassu <roberto.sassu@...wei.com>,
        Eric Biggers <ebiggers@...nel.org>,
        Antony Vennard <antony@...nard.ch>
CC:     James Bottomley <James.Bottomley@...senpartnership.com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "dwmw2@...radead.org" <dwmw2@...radead.org>,
        "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "linux-fscrypt@...r.kernel.org" <linux-fscrypt@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "zohar@...ux.ibm.com" <zohar@...ux.ibm.com>
Subject: RE: [PATCH 00/14] KEYS: Add support for PGP keys and signatures

> From: Roberto Sassu [mailto:roberto.sassu@...wei.com]
> Sent: Wednesday, January 19, 2022 2:25 PM
> > From: Eric Biggers [mailto:ebiggers@...nel.org]
> > Sent: Wednesday, January 19, 2022 12:04 AM
> > On Tue, Jan 18, 2022 at 09:50:21PM +0100, Antony Vennard wrote:
> > >
> > > Hi All,
> > >
> > > On 17/01/2022 16:02, James Bottomley wrote:
> > > > On Mon, 2022-01-17 at 15:34 +0100, Jason A. Donenfeld wrote:
> > > > > Hi,
> > > > >
> > > > > While it looks like you put a lot of work into this patchset, I think
> > > > > the general idea of adding PGP *to the kernel* is a pretty daunting
> > > > > proposition. The general consensus in the crypto engineering world is
> > > > > that PGP ought to be on its way out. We definitely don't want to
> > > > > perpetuate this project-on-life-support into the permanence of kernel
> > > > > code. Some quick Google searches will reveal a litany of blog posts
> > > > > to the tune of, "why oh why are people still using this?" Here's one
> > > > > from 2019:
> > > > > https://latacora.micro.blog/2019/07/16/the-pgp-problem.html . I
> > > > > think these are arguments to take seriously. And even if you disagree
> > > > > with some parts, you may want to consider whether the remaining parts
> > > > > warrant a bit of pause before adding this to the kernel and
> > > > > perpetuating PGP's design further.
> > >
> > > So while I understand why this is being proposed and clearly effort has gone
> > > into it, I also think it is not the right approach. It seems this proposal
> > > is to include a full PGP packet parser and verification logic in the kernel
> > > as an equivalent to allow PGP signatures to be submitted via
> > > FS_IOC_ENABLE_VERITY:
> > >
> > > "FS_IOC_ENABLE_VERITY accepts a pointer to a PKCS#7 formatted detached
> > > signature in DER format of the file’s fs-verity digest."
> > >
> >
> > It's worth noting that if fs-verity built-in signatures are used, a trusted
> > userspace program is still required to determine and enforce the policy of
> which
> > files are required to be signed.  The kernel only handles the actual signature
> > verification.  This was basically a proof-of-concept which reused the kernel's
> > module signature verification code (which happens to use PKCS#7).
> 
> Just to show how the fsverity code will look like after adding support
> for PGP signatures:
> 
> +       switch (vi->type) {
> +       case PKEY_ID_PKCS7:
> +               err = verify_pkcs7_signature(d, sizeof(*d) + hash_alg->digest_size,
> +                                            signature, sig_size, fsverity_keyring,
> +                                            VERIFYING_UNSPECIFIED_SIGNATURE,
> +                                            NULL, NULL);
> +               break;
> +       case PKEY_ID_PGP:
> +               err = verify_pgp_signature(d, sizeof(*d) + hash_alg->digest_size,
> +                                          signature, sig_size, fsverity_keyring,
> +                                          VERIFYING_UNSPECIFIED_SIGNATURE,
> +                                          NULL, NULL);
> +               break;
> +       default:
> +               err = -EOPNOTSUPP;
> +       }
> 
> As you can see, the change will be straightforward.
> 
> On user space side, I plan to add the capability to fsverity-utils
> to produce a PGP signature with the GPG key passed by rpmsign.

At the end, it was not necessary. With this patch set, rpmsign is able
to produce a PGP signature without modifications to fsverity-utils:

https://github.com/robertosassu/rpm/commits/fsverity-gpg-v1

The modifications are very minimal, basically consist in introducing
the new function rpmVeritySignFileGPG() that creates a file with
the fsverity_formatted_digest structure, and signs it with the
exposed function makeGPGSignatureArgs().

The fsverity rpm plugin works without modification, and the
kernel takes care of the verification of the PGP signatures when
a package is installed.

I wrote a more detailed procedure to sign and install a package
with fsverity signatures in the PGP format. It can be found here:

https://www.spinics.net/lists/fedora-devel/msg296562.html

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Zhong Ronghua

> > I'd encourage new users to either go all-in on a userspace solution, using a
> > trusted userspace program to verify signatures of fs-verity file digests;
> > *or* go all-in on an in-kernel solution, using the IMA support for fs-verity
> > which Mimi Zohar is working on.  A userspace solution could use a simple
> 
> Probably, there is also the third option of an LSM (such as IPE) that gets
> from fsverity the information if the signature was validated, and decide
> depending on a policy. I would also expose the information about the
> restriction imposed on the keyring from which the key used to verify
> the signature was found.
> 
> Maybe IMA could use this approach too, which would avoid the need
> of introducing another signature format. If that is desired, you might
> want to coordinate with the authors of a Fedora feature:
> 
> https://fedoraproject.org/wiki/Changes/FsVerityRPM
> 
> which, as far as I know, plan to use the signature format already
> upstreamed.
> 
> Thanks
> 
> Roberto
> 
> HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
> Managing Director: Li Peng, Zhong Ronghua
> 
> > signature format, using a modern algorithm such as Ed25519.  IMA uses a
> simple
> > signature format too, though it uses a complex format (X.509) for public keys.
> >
> > - Eric

Powered by blists - more mailing lists