[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zc-s-42WoZhW_2c8@casper.infradead.org>
Date: Fri, 16 Feb 2024 18:44:11 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Roberto Sassu <roberto.sassu@...weicloud.com>
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, 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?
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'?
Powered by blists - more mailing lists