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'?
