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

[H. Peter Anvin]

On February 20, 2024 2:55:12 AM PST, Petr Tesarik <petr.tesarik1@xxxxxxxxxxxxxxxxxxx> wrote:
>On 2/16/2024 6:08 PM, H. Peter Anvin wrote:
>> On February 16, 2024 8:53:01 AM PST, Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> 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.
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> Roberto
>>>
>>>
>> 
>> Ok, at least one of those assumptions is false, and *definitely* this approach seems to be a solution in search of a problem.
>
>As a matter of fact, there is some truth to this observation.
>
>The frustrating story of Roberto's PGP parser sparked the idea, but it
>would clearly be overkill to add all this code just for this one parser.
>I started looking around if there are other potential uses of a sandbox
>mode, which might justify the effort. I quickly found out that it is
>difficult to find a self-contained part of the kernel.
>
>Now I believe that these dependencies among different parts of the
>kernel present an issue, both to kernel security and to maintainability
>of the source code. Even if sandbox mode as such is rejected (hopefully
>with an explanation of the reasons), I believe that it is good to split
>the kernel into smaller parts and reduce their interdependencies. In
>this sense, sandbox mode is a way to express and enforce the remaining
>dependencies.
>
>Petr T

Congratulations. You just reinvented the microkernel.