> 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.
> 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
|