Message-ID: <393a1cd5-a212-4b04-9ff2-744772c21106@canonical.com>
Date: Wed, 2 Oct 2024 22:35:27 -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 21:26, Tetsuo Handa wrote:
> 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.

which is sadly a very valid argument. Coming from the distro side of things
it is a very real problem. I tend to advocate for giving the user choice
where we can but there is more than one occasion where Ubuntu has had
to declare bug bankruptcy on outstanding kernel bugs because the backlog
was impossible to handle.

> 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.
> 
I do understand that. The problem is that out of tree doesn't do that.
 From a distro perspective out of tree is more work, and is very problematic
from a code signing perspective.

Code signing isn't going away, if anything its become a requirement to
support the majority of users. Loading unsigned modules, code, even
bpf is a problem.

Sure individual users can disable secure boot etc but at the distro
level we need to support secure boot out of the box. Out of tree code
really just isn't compatible with this.

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

>>                                            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,
> 
true. that is a limitation of the cryptography that is being used, and
I don't see a way to fix that

>>
>> 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).
> 
yes it can, it has chosen not to. As I have said before that is
a choice/political reason, not technical. I wish I had a solution to this
problem for you but I don't. What I can say is Tomoyo adding the ability to
load out of tree code that isn't signed is going to force Ubuntu to do
the same and disable it. I really don't want to do that, I would rather
leave the choice available to our users.

It may be a trade-off worth making for you/Tomoyo if it fixed your
problem with RHEL/Fedora but I don't see it fixing that problem either.

Powered by blists - more mailing lists