> From: Roberto Sassu [mailto:roberto.sassu@xxxxxxxxxx] > Sent: Wednesday, January 19, 2022 2:25 PM > > From: Eric Biggers [mailto:ebiggers@xxxxxxxxxx] > > 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
