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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux