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.
