On Sun, 2024-09-15 at 10:40 +0200, Linus Torvalds wrote: > On Sun, 15 Sept 2024 at 10:08, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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? Thanks Roberto [1] https://lore.kernel.org/linux-kernel/32081.1171560770@xxxxxxxxxx/ [2] https://lore.kernel.org/linux-integrity/20240905150543.3766895-9-roberto.sassu@xxxxxxxxxxxxxxx/ [3] https://lore.kernel.org/lkml/20230317145240.363908-1-roberto.sassu@xxxxxxxxxxxxxxx/#t [4] https://lore.kernel.org/linux-integrity/eb31920bd00e2c921b0aa6ebed8745cb0130b0e1.camel@xxxxxxxxxxxxxxx/ [5] https://lwn.net/Articles/853489/
