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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 21 Feb 2024 06:02:30 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Petr Tesarik <petr.tesarik1@...wei-partners.com>,
        Roberto Sassu <roberto.sassu@...weicloud.com>,
        Matthew Wilcox <willy@...radead.org>,
        Petr Tesarik <petrtesarik@...weicloud.com>
CC: Dave Hansen <dave.hansen@...el.com>,
        Petr Tesařík <petr@...arici.cz>,
        Jonathan Corbet <corbet@....net>, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        Andy Lutomirski <luto@...nel.org>, Oleg Nesterov <oleg@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>, Xin Li <xin3.li@...el.com>,
        Arnd Bergmann <arnd@...db.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        Kees Cook <keescook@...omium.org>,
        "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
        Pengfei Xu <pengfei.xu@...el.com>,
        Josh Poimboeuf <jpoimboe@...nel.org>, Ze Gao <zegao2021@...il.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Kai Huang <kai.huang@...el.com>, David Woodhouse <dwmw@...zon.co.uk>,
        Brian Gerst <brgerst@...il.com>, Jason Gunthorpe <jgg@...pe.ca>,
        Joerg Roedel <jroedel@...e.de>,
        "Mike Rapoport (IBM)" <rppt@...nel.org>,
        Tina Zhang <tina.zhang@...el.com>,
        Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        David Howells <dhowells@...hat.com>
Subject: Re: [RFC 6/8] KEYS: PGP data parser

On February 20, 2024 2:55:12 AM PST, Petr Tesarik <petr.tesarik1@...wei-partners.com> 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@...weicloud.com> 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@...hat.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.
>>>
>>> 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.