linux-kernel - Re: [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures

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: <CAMj1kXH8nWtAzX+9xc2tLyy5d0w==JNQCMJBAbL=LdcF+XrYkw@mail.gmail.com>
Date: Fri, 13 Sep 2024 12:46:09 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>, 
	Roberto Sassu <roberto.sassu@...weicloud.com>, dwmw2@...radead.org, davem@...emloft.net, 
	linux-kernel@...r.kernel.org, keyrings@...r.kernel.org, 
	linux-crypto@...r.kernel.org, zohar@...ux.ibm.com, 
	linux-integrity@...r.kernel.org, torvalds@...ux-foundation.org, 
	roberto.sassu@...wei.com
Subject: Re: [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures

On Fri, 13 Sept 2024 at 11:32, David Howells <dhowells@...hat.com> wrote:
>
> Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> > Personally I don't think the argument above holds water.  With
> > IPsec we had a similar issue of authenticating untrusted peers
> > using public key cryptography.  In that case we successfully
> > delegated the task to user-space and it is still how it works
> > to this day.

This is slightly disingenuous. The kernel itself has no need to trust
the peer - it only manages the network pipe and authenticates/decrypts
the packets on behalf of user space.

The situation would be radically different if the kernel itself would
communicate over IPsec (or HTTPS) directly.

Likewise for module loading: there is no way the authentication can be
delegated to user space, unless that user space component is
authenticated by the kernel (and runs in a special, hardened context).
>
> It transpires that we do actually need at least a PGP parser in the kernel -
> and it needs to be used prior to loading any modules: some Lenovo Thinkpads,
> at least, may have EFI variables holding a list of keys in PGP form, not X.509
> form.
>
> For example, in dmesg, you might see:
>
> May 16 04:01:01 localhost kernel: integrity: Loading X.509 certificate: UEFI:MokListRT (MOKvar table)
> May 16 04:01:01 localhost kernel: integrity: Problem loading X.509 certificate -126
>

MokListRT is a shim construct, which is a component in the downstream
distro boot chain. It is not part of EFI, and in your case, this is
unlikely to be specific to Lenovo systems.

> On my laptop, if I dump this variable:
>
>         efivar -e /tmp/q --name=605dab50-e046-4300-abb6-3dd810dd8b23-MokListRT
>
> And then looking at the data exported:
>
>         file /tmp/q
>
> I see:
>
>         /tmp/q: PGP Secret Sub-key -
>
> The kernel doesn't currently have a PGP parser.  I've checked and the value
> doesn't parse as ASN.1:
>
>         openssl asn1parse -in /tmp/q -inform DER
>             0:d=0  hl=2 l=  21 prim: cont [ 23 ]
>         Error in encoding
>         001EBA93B67F0000:error:0680007B:asn1 encoding routines:ASN1_get_object:header too long:crypto/asn1/asn1_lib.c:105:
>
> which would suggest that it isn't X.509.
>

This should be fixed in shim not the kernel.