Re: [GIT PULL] tomoyo update for v6.12

[Tetsuo Handa]

On 2024/10/03 11:45, John Johansen wrote:
>> 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.

The reason Fedora cannot enable TOMOYO is lack of bandwidth.
You've just said "Bandwidth is a very real issue". Thus, I need a solution
that can solve the bandwidth problem. The question is how we can control
division of role (share the workload) in a secure manner.

> 
> Users are still free to build their own kernels they just don't get
> support or certification when using them.

Nobody can provide bandwidth (or infrastructure) for supporting their
locally built kernels.

>                                           Stopping the load of out of
> tree modules that aren't signed is in general good security policy.

Yes, distributors can prevent load of out-of-tree modules that aren't
signed. That is good for security. But building kernels locally cannot
utilize signed modules functionality. Also,

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

TOMOYO is one of in-tree modules that can be signed together when building
distribution kernels. Fedora can provide tomoyo.ko as a signed-but-unsupported
module (i.e. excluded from main kernel package that is supported by
distributors but provided as a separate package that is not supported by
distributors).