Message-ID: <d1b88a1d2affbfb89ccd9131357d84580f107360.camel@huaweicloud.com>
Date: Wed, 28 Feb 2024 18:58:30 +0100
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Petr Tesarik <petrtesarik@...weicloud.com>, 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>, "H. Peter Anvin"
 <hpa@...or.com>, 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>, Petr Tesarik
 <petr.tesarik1@...wei-partners.com>
Subject: Re: [RFC 6/8] KEYS: PGP data parser

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@...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.
> > 
> > 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

Powered by blists - more mailing lists