Re: [RFC 6/8] KEYS: PGP data parser

[Matthew Wilcox]

On Fri, Feb 16, 2024 at 05:53:01PM +0100, Roberto Sassu wrote:
> On Fri, 2024-02-16 at 16:44 +0000, Matthew Wilcox wrote:
> > On Fri, Feb 16, 2024 at 04:24:33PM +0100, Petr Tesarik wrote:
> > > From: David Howells <dhowells@xxxxxxxxxx>
> > > 
> > > Implement a PGP data parser for the crypto key type to use when
> > > instantiating a key.
> > > 
> > > This parser attempts to parse the instantiation data as a PGP packet
> > > sequence (RFC 4880) and if it parses okay, attempts to extract a public-key
> > > algorithm key or subkey from it.
> > 
> > I don't understand why we want to do this in-kernel instead of in
> > userspace and then pass in the actual key.
> 
> Sigh, this is a long discussion.

Well, yes.  When you don't lay out why this is of value, it turns into a
long discussion.  This isn't fun for me either.

> PGP keys would be used as a system-wide trust anchor to verify RPM
> package headers, which already contain file digests that can be used as
> reference values for kernel-enforced integrity appraisal.

The one example we have of usage comes in patch 7 of this series and is:

gpg --dearmor < <PGP key> | keyctl padd asymmetric "" @u

And you're already using two userspace programs there.  Why not a third?

gpg --dearmor < <PGP key> | ./scripts/parse-pgp-packets | keyctl padd asymmetric "" @u

> With the assumptions that:
> 
> - In a locked-down system the kernel has more privileges than root
> - The kernel cannot offload this task to an user space process due to
>   insufficient isolation
> 
> the only available option is to do it in the kernel (that is what I got
> as suggestion).

This sounds like there's some other way of getting the key into the
kernel which doesn't rely on userspace.  Or are you assuming that nobody
bothered to trojan 'cat'?