lkml.org 
[lkml]   [2024]   [Feb]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC 6/8] KEYS: PGP data parser
From
On 2/16/2024 7:44 PM, Matthew Wilcox wrote:
> 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@redhat.com>
>>>>
>>>> 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?

I think this is very easy to answer. Why not extracting the public key
from an x509 certificate in user space, sending it to the kernel, and
using it for kernel module verification?

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

Apologies for not providing the full information at once. I'm worried
that would be too long, and pieces can be lost in the way. If it is not
a problem, I'm going to clarify on request.

Ok, so, I'm not going to use cat to upload the PGP keys. These will be
embedded in the kernel image, when the Linux distribution vendors build
their kernel.

This works for both secure boot and trusted boot, since the kernel image
can be measured/verified by the boot loader.

Another source for keys is the MOK database, since users might want the
ability to verify their own software, which does not come from the Linux
distribution.

I briefly anticipated the full picture, but I will tell it more explicitly.

The kernel, with the embedded PGP keys, will be able to verify the
signature of the RPM package headers.

A component that I recently developed, the digest_cache LSM, has the
ability to extract file digests from RPM headers and provide a simple
interface for IMA, IPE, BPF LSM and any other component to query the
calculated digest of files being accessed, and allow/deny access to them
depending on whether the query is successful or not.

I already anticipate the question, if you have the problem parsing PGP
keys, why don't you have the problem parsing RPM package headers?

I started finding a solution before this became available, and the only
alternative I found was to formally verify my code. So, I took Frama-C,
wrote the assertions, and verified that not only the code is
functionally correct for correct sequences of bytes, but that there is
no illegal memory access for any arbitrary sequence (unfortunately, I
can prove for a small buffer size).

So, I'm probably going to do the same for the PGP parser, if this does
not fly. But, we were very optimistic that this could be a valid
alternative!

Roberto


\
 
 \ /
  Last update: 2024-05-27 15:07    [W:0.142 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site