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]

Message-ID: <773dd9fb-e668-4652-8b24-712553bb7ab1@huawei-partners.com>
Date: Tue, 20 Feb 2024 11:55:12 +0100
From: Petr Tesarik <petr.tesarik1@...wei-partners.com>
To: "H. Peter Anvin" <hpa@...or.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 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