On 2024/10/03 11:45, John Johansen wrote:
But due to above-mentioned realities, your assertion no longer stands.Yes, and this is an intentional choice on the base of the distro about
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).
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 solutionI do understand that. The problem is that out of tree doesn't do that.
that can solve the bandwidth problem. The question is how we can control
division of role (share the workload) in a secure manner.
right
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.
true. that is a limitation of the cryptography that is being used, andStopping 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,
yes it can, it has chosen not to. As I have said before that is
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).