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

From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Petr Tesarik" <petrtesarik@huaweicloud.com>,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Petr Tesařík" <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>
Subject: Re: [RFC 6/8] KEYS: PGP data parser
Date: Wed, 28 Feb 2024 18:58:30 +0100	[thread overview]
Message-ID: <d1b88a1d2affbfb89ccd9131357d84580f107360.camel@huaweicloud.com> (raw)
In-Reply-To: <5b0ce7ef-3f4e-4c1b-a0b7-bf48e8169c4e@huaweicloud.com>

On Fri, 2024-02-16 at 20:54 +0100, Roberto Sassu wrote:
> 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.

Not the proper thread, but since we talked about it...

I finally put together the PGP key and signature parser, the
digest_cache LSM and the IMA integration patch sets, and built three
openSUSE Tumbleweed packages (kernel, digest-cache-tools, dracut),
which basically enable the integrity features that the kernel (IMA)
supports:

- IMA measurement list with RPM headers and (eventually) unknown files 
  that are not from Tumbleweed;

- Ability to obtain a deterministic TPM PCR value, suitable for sealing
  of TPM keys

- Out of the box integrity enforcement on executable code, based on the
  provenance from openSUSE Tumbleweed; nothing else is required other
  than those three packages

An introduction and a guide with configuration steps can be found at:

https://github.com/linux-integrity/digest-cache-tools

I would also appreciate your comments.

Thanks

Roberto

> 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