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 <herb...@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
