On 12.01.2022 10:16, Roberto Sassu wrote:
From: Maciej S. Szmigiero [mailto:mail@xxxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, January 11, 2022 9:33 PM
On 11.01.2022 19:03, Roberto Sassu wrote:
Support for PGP keys and signatures was proposed by David long time ago,
before the decision of using PKCS#7 for kernel modules signatures
verification was made. After that, there has been not enough interest to
support PGP too.
Lately, when discussing a proposal of introducing fsverity signatures in
Fedora [1], developers expressed their preference on not having a separate
key for signing, which would complicate the management of the distribution.
They would be more in favor of using the same PGP key, currently used for
signing RPM headers, also for file-based signatures (not only fsverity, but
also IMA ones).
Aren't PGP keys simply RSA / ECC / EdDSA keys with additional metadata?
Can't they be unwrapped from their (complex) PGP format in userspace and
loaded raw into the kernel, in a similar way as they are sometimes used
for SSH authentication?
Probably, this would be possible by introducing a new asymmetric
key subtype parsing PGP keys and signatures in a more simple format,
after conversion by user space. But still, a parser would be required.
To be honest, I would prefer to implement (actually David did) a
parser following an RFC, than developing a new one.
A parser in userspace is preferred to one in kernel since if there is
a bug somewhere its consequences are much less severe.
And experience shows that parsers are especially prone to bugs.
A userspace implementation can also be tightly sandboxed for extra
security.
There are many existing OpenPGP parsing libraries to choose from.
This will save us from having to add complex parsers (a well-known source
of bugs) into the kernel - I guess there aren't any plans to add an
in-kernel PGP Web of Trust implementation.
I extensively tested the implementation with an ad-hoc fault injector,
to see if the code can correctly handle errors. I also developed a
fuzzer to corrupt the data before it is read by the kernel. Finally,
I checked that there are not memory leaks. But I agree, there could
still be bugs.
If you mean that a key can be added to the kernel if is vouched for
by another key in the built-in keyring, I actually implemented this
(was missing in the original implementation). Some keyrings, e.g. .ima,
have this restriction.
The way this works is that, whenever you add a PGP key to the
kernel, the parser takes not only the public key and the user ID,
but also its signature by the same or another PGP key.
The signature is verified when the key is added to the keyring
with that restriction, and only if the verification is successful
the key can be added.
I understand but it would be great to make use as much as possible of
the existing in-kernel signature verification mechanisms.
Roberto
Thanks,
Maciej
