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] [day] [month] [year] [list]

Message-ID: <d5387ff4-06c7-4115-bd53-1c485e3743ec@huaweicloud.com>
Date: Fri, 4 Oct 2024 12:42:32 +0200
From: Roberto Sassu <roberto.sassu@...weicloud.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 Herbert Xu <herbert@...dor.apana.org.au>
Cc: dhowells@...hat.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, roberto.sassu@...wei.com,
 linux-security-module@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>
Subject: Re: [PATCH v3 00/14] KEYS: Add support for PGP keys and signatures

On 9/26/2024 11:41 AM, Roberto Sassu wrote:
> On Sun, 2024-09-15 at 10:40 +0200, Linus Torvalds wrote:
>> On Sun, 15 Sept 2024 at 10:08, Herbert Xu <herbert@...dor.apana.org.au> wrote:
>>>
>>> If the aformentioned EFI use-case is bogus, then distro package
>>> verification is going to be the only application for PGP keys in
>>> the kernel.
>>
>> So I haven't actually seen _that_ series, but as mentioned it does
>> smell pretty conceptually broken to me.
>>
>> But hey, code talks, bullshit walks. People can most certainly try to
>> convince me.
> 
> The solution has three parts.
> 
> 1. The kernel verifies the RPM header with a PGP key embedded in the
> kernel, and provided by the Linux distribution vendor.
> 
> 2. The Integrity Digest Cache parses the verified RPM header in the
> kernel and feeds one of the existing LSMs (IMA, IPE and BPF LSM) with
> the digests extracted from the RPM header.
> 
> 3. The LSMs compare the fsverity digest they find in the filesystem
> with the authenticated ones from the RPM header, and might deny access
> to the file if the digests don't match.
> 
> At this point, RPM headers don't contain fsverity digests, only file
> content digests, but this is an orthogonal problem.
> 
> 
> I had a look at previous threads on similar topics, to find your
> position on the matter.
> 
> I got that you would not be probably against (1), and maybe not (3).
> 
> However, we still need a source telling whether the fsverity digest in
> the filesystem is the same of one calculated by Linux distributions
> during build. That is what the Integrity Digest Cache provides.
> 
> Regarding (2), maybe I'm missing something fundamental, but isn't
> parsing the ELF format of kernel modules from the kernel similar?
> 
> Cannot really go to user space at this point, since the authenticated
> fsverity digests are directly consumed by LSMs. Also, as David pointed
> out in this thread [1], there is no obligation for user space to call
> any signature verification function before executing a file, this task
> must be done by an LSM.
> 
> I'm aware that we should not run unnecessary code in the kernel. I
> tried to mitigate this issue by striping the parsing functionality to
> the minimum (220 LOC), and formally verifying it with the Frama-C
> static analyzer. The parser is available here [2].
> 
> I'm also aware that this is not the long term solution, but I didn't
> find much support on the alternatives, like a trustworthy user mode
> driver [3][4] (isolated from other root processes) and signed eBPF
> programs [5].
> 
> What it would be the right way to proceed, in your opinion?

If I remove the parsers completely from the kernel, and attach them 
dynamically with eBPF, would you reconsider my patch set?

Thanks

Roberto