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

[Roberto Sassu]

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 at gondor.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