Message-ID: <2e182814-9317-4de1-ab96-b3b1eeb89733@canonical.com>
Date: Wed, 2 Oct 2024 19:45:46 -0700
From: John Johansen <john.johansen@...onical.com>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
 Paul Moore <paul@...l-moore.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 Jonathan Corbet <corbet@....net>, LKML <linux-kernel@...r.kernel.org>,
 linux-security-module@...r.kernel.org
Subject: Re: [GIT PULL] tomoyo update for v6.12

On 10/2/24 16:09, Tetsuo Handa wrote:
> On 2024/10/02 23:01, Paul Moore wrote:
>>> Now that built-in LSM modules started using __ro_after_init static calls, !built-in
>>> LSM modules can start using !__ro_after_init linked list without affecting built-in
>>> LSM modules. I can't understand why Paul does not like it.
>>
>> A *lot* of effort has gone into both hardening and improving the
>> performance of the LSM framework.  I'm loath to introduce anything
>> which would take away from those gains, especially if it is only done
>> to satisfy out-of-tree LSMs, or users who don't agree with their
>> distro kernel's build-time configuration.
> 
> Forcing distro users to rebuild distro kernels (with or without modified
> kernel configurations) is no longer a viable solution.
> 
and you think this fixes that? All this is going to do is force distros to
disable Tomoyo to be able to continue to support their security stance.

> Since cryptography (e.g. module signing keys) is getting used inside kernels,
> noone except the one who has the private key and has built the original kernel
> can reproduce the same behavior/functionality (even without modified kernel
> configurations). Also, from package management perspective, users get confused
> by being forced to use different package names/versions (when installing kernel
> related packages) and breaking package dependency (when installing userspace
> packages). You said
> 
>    Comparing userspace applications to kernel code isn't a fair
>    comparison as a userspace application can generally be added without
>    impacting the other applications on the system.
> 
>    Anyone is always free to build their own kernel with whatever code
>    changes they like, this is the beauty of the kernel source being
>    available and licensed as Open Source.  You are free to build a kernel
>    with whatever LSM you like included and enabled.  You have been shown
>    examples on how to do this in previous threads.
> 
> at https://lkml.kernel.org/r/CAHC9VhQq0-D=p9Kicx2UsDrK2NJQDyn9psL-PWojAA+Y17WiFQ@mail.gmail.com .
> But due to above-mentioned realities, your assertion no longer stands.
> Kernel source itself might be open, but private keys cannot be open.
> The vmlinux cannot be rebuilt without forcing penalties (i.e. having a
> negative impact on the user side, which cannot be a viable solution).
> 
> 
Yes, and this is an intentional choice on the base of the distro about
what they support and what is required to meet contractual obligations.

Users are still free to build their own kernels they just don't get
support or certification when using them. Stopping the load of out of
tree modules that aren't signed is in general good security policy.

Let me be explicitly clear. If Tomoyo is by-passing module signing, and
exporting the LSM interface to loadable modules Ubuntu will be forced
to disable Tomoyo.

This change is not going to get you closer to what you want. It is
going to force the distros that currently build in Tomoyo to disable
it entirely.

Powered by blists - more mailing lists