Received-SPF: pass (google.com: domain of linux-kernel+bounces-69268-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <5b0ce7ef-3f4e-4c1b-a0b7-bf48e8169c4e@huaweicloud.com>
Date: Fri, 16 Feb 2024 20:54:25 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC 6/8] KEYS: PGP data parser
Content-Language: en-US
To: Matthew Wilcox <willy@infradead.org>
Cc: Petr Tesarik <petrtesarik@huaweicloud.com>,
 Dave Hansen <dave.hansen@intel.com>, =?UTF-8?B?UGV0ciBUZXNhxZnDrWs=?=
 <petr@tesarici.cz>, Jonathan Corbet <corbet@lwn.net>,
 Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
 Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>,
 "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@kernel.org>,
 "H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@kernel.org>,
 Oleg Nesterov <oleg@redhat.com>, Peter Zijlstra <peterz@infradead.org>,
 Xin Li <xin3.li@intel.com>, Arnd Bergmann <arnd@arndb.de>,
 Andrew Morton <akpm@linux-foundation.org>,
 Rick Edgecombe <rick.p.edgecombe@intel.com>,
 Kees Cook <keescook@chromium.org>,
 "Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
 Pengfei Xu <pengfei.xu@intel.com>, Josh Poimboeuf <jpoimboe@kernel.org>,
 Ze Gao <zegao2021@gmail.com>,
 "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
 Kai Huang <kai.huang@intel.com>, David Woodhouse <dwmw@amazon.co.uk>,
 Brian Gerst <brgerst@gmail.com>, Jason Gunthorpe <jgg@ziepe.ca>,
 Joerg Roedel <jroedel@suse.de>, "Mike Rapoport (IBM)" <rppt@kernel.org>,
 Tina Zhang <tina.zhang@intel.com>, Jacob Pan
 <jacob.jun.pan@linux.intel.com>,
 "open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
 open list <linux-kernel@vger.kernel.org>, David Howells
 <dhowells@redhat.com>, Petr Tesarik <petr.tesarik1@huawei-partners.com>
References: <fb4a40c7-af9a-406a-95ab-406595f3ffe5@intel.com>
 <20240216152435.1575-1-petrtesarik@huaweicloud.com>
 <20240216152435.1575-7-petrtesarik@huaweicloud.com>
 <Zc-Q5pVHjngq9lpX@casper.infradead.org>
 <5916fa3ac3d0ce2ade71e7ed1c9eb6923e374c1f.camel@huaweicloud.com>
 <Zc-s-42WoZhW_2c8@casper.infradead.org>
From: Roberto Sassu <roberto.sassu@huaweicloud.com>
In-Reply-To: <Zc-s-42WoZhW_2c8@casper.infradead.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2/16/2024 7:44 PM, Matthew Wilcox wrote:
> On Fri, Feb 16, 2024 at 05:53:01PM +0100, Roberto Sassu 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@redhat.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.
> 
> Well, yes.  When you don't lay out why this is of value, it turns into a
> long discussion.  This isn't fun for me either.
> 
>> 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.
> 
> The one example we have of usage comes in patch 7 of this series and is:
> 
> gpg --dearmor < <PGP key> | keyctl padd asymmetric "" @u
> 
> And you're already using two userspace programs there.  Why not a third?

I think this is very easy to answer. Why not extracting the public key 
from an x509 certificate in user space, sending it to the kernel, and 
using it for kernel module verification?

> gpg --dearmor < <PGP key> | ./scripts/parse-pgp-packets | keyctl padd asymmetric "" @u
> 
>> 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).
> 
> This sounds like there's some other way of getting the key into the
> kernel which doesn't rely on userspace.  Or are you assuming that nobody
> bothered to trojan 'cat'?

Apologies for not providing the full information at once. I'm worried 
that would be too long, and pieces can be lost in the way. If it is not 
a problem, I'm going to clarify on request.

Ok, so, I'm not going to use cat to upload the PGP keys. These will be 
embedded in the kernel image, when the Linux distribution vendors build 
their kernel.

This works for both secure boot and trusted boot, since the kernel image 
can be measured/verified by the boot loader.

Another source for keys is the MOK database, since users might want the 
ability to verify their own software, which does not come from the Linux 
distribution.

I briefly anticipated the full picture, but I will tell it more explicitly.

The kernel, with the embedded PGP keys, will be able to verify the 
signature of the RPM package headers.

A component that I recently developed, the digest_cache LSM, has the 
ability to extract file digests from RPM headers and provide a simple 
interface for IMA, IPE, BPF LSM and any other component to query the 
calculated digest of files being accessed, and allow/deny access to them 
depending on whether the query is successful or not.

I already anticipate the question, if you have the problem parsing PGP 
keys, why don't you have the problem parsing RPM package headers?

I started finding a solution before this became available, and the only 
alternative I found was to formally verify my code. So, I took Frama-C, 
wrote the assertions, and verified that not only the code is 
functionally correct for correct sequences of bytes, but that there is 
no illegal memory access for any arbitrary sequence (unfortunately, I 
can prove for a small buffer size).

So, I'm probably going to do the same for the PGP parser, if this does 
not fly. But, we were very optimistic that this could be a valid 
alternative!

Roberto