TOMOYO's pull request for v6.12

[Simon Thoby]

On 10/5/24 6:30 PM, Paul Moore wrote:
> On Sat, Oct 5, 2024 at 3:11 AM Tetsuo Handa
> <penguin-kernel at i-love.sakura.ne.jp> wrote:
>> I think that this pull request succeeded in revealing what LSM community thinks.
>> Each developer is thinking different things. One thinks "anyone can rebuild kernels
>> with whatever changes", but that opinion ignored secure boot / module signing part.
> 
> As I believe that I'm the developer quoted above, let me say that my
> comment did not ignore UEFI SB.  The Machine Owner Key (MOK) concept
> provided by shims/bootloaders is designed just for this use case.
> More advanced users can even replace the UEFI SB key databases, on
> hardware that supports it, with their own to permit loading of their
> self-built kernels without the need for the MOK; this is arguably one
> of the most "secure" UEFI SB configurations.
> 
> I've successfully used MOK on my own systems to support my own kernel
> builds, and I've successfully replaced the UEFI SB key databases in
> VMs to use UEFI SB and my own kernel builds without MOK.
> 

Indeed, I'm probably sidetracking the discussion a bit, but I have met all three use
cases both personally and professionally:
- Signing an out-of-tree kernel modules with a local certificate (MOK) enrolled in the
  MOKList via shim (e.g. to support Nvidia GPUs on SecureBoot-enabled machines)
- Enrolling user boot keys (changing the PK, adding my own KEK to Microsoft's and the platform
  manufacturer's, then extending the DB list) the signing my kernel with my own key
- Completely replacing the secure boot keys to only allow my own (sadly, this may be risky
  on some platforms, like ThinkPads, where essential UEFIs drivers may not load, thus
  bricking the device)

I say all this to emphasize that the options outlined by Paul are not theoretical, but
very practical use cases that one may encounter in the industry (and I have, even
in fairly conservative industries).
In addition, I strongly believe this is the way to go: any kernel module or dynamic
configuration (if I push this idea to the extreme, maybe in the future this could
even include eBPF payloads in some hardened configurations) should be signed by a trusted
authority to be loaded in the kernel.
That authority may be the Linux distribution, but it can also be you (or your company
IT department), thanks to MOK (or its heavier alternatives).
You retain the flexibility to load kernel modules not built by the distributor,
or even out-of-tree modules, but without degrading the security of your computers
(assuming the signing keys are properly protected, of course).

Perhaps you would be better served by providing your users with a snippet of documentation
explaining how to configure MOK and to rebuild the RHEL kernel with TOMOYO enabled?
To be fair, I know that your customers may find this a time-consuming ordeal compared to using
the official kernel - especially as you want to keep up with the frequent updates.
But OTOH that's not end-of-the-world complexity either, which makes it fine for occasional use,
e.g. to behave like "a sort of system-wide strace-like profiler" (I'm guessing your customers
are only doing this operation from time to time, not continuously in production).
There's no perfect solution I guess, but to keep lobbying distributors to enabled TOMOYO
in their kernels.

Simon