Message-ID: <a0de84de-8c20-46b9-ba61-44d35e7cdc58@canonical.com>
Date: Fri, 4 Oct 2024 20:59:10 -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 23:16, Tetsuo Handa wrote:
> On 2024/10/03 14:35, John Johansen wrote:
>> 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.
> 
> Confused. If use of BPF is a problem, use of BPF-LSM is also a problem?

yes it is. Pressures being what they are, it is enabled for some of our
kernels. Signed BPF would be required to get it available every where.

> If one were able to implement security modules using BPF-LSM, such modules
> are headache for distributors? If so, BPF based LSM modules can't be a
> candidate for replacing C based LSM modules...
> 

I have never argued they were. But they are currently the only solution for
out of tree LSM modules if you don't want to rebuild the kernel.

>>
>> 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.
> 
> More we want to enforce protecting with module signing, more we need to make
> whatever code built-in and run in the kernel space. Upstream-first pressure
> will push whatever code for inclusion into the upstream kernel.
> 
> 
> 
>>> 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 does "it" referring to? Fedora has chosen not to build TOMOYO into Fedora's
> vmlinux. But I haven't heard from Fedora that Fedora won't ship tomoyo.ko as a
> separate package.
> 
yeah fedora/RHEL, they don't build apparmor either. And I do not believe that
building tomoyo.ko will get them to ship it in a separate package. That separate
package is more work than a builtin tomoyo and the kernel memory savings are
minimal.

With KP's performance patch the performance overhead of a builtin tomoyo is
negligible.

>>                               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.
> 
> How is tomoyo.ko connected to loading of out-of-tree code? If the module signing
> can prevent unsigned modules from loading, where is the possibility of loading
> unsigned LSM modules even if LSM hooks are exported to loadable modules?
> 

sorry was tired and in rush, and dumping in the other worries I have here. Exporting
symbols itself has nothing to do with module signing. However as Kees pointed
out in another email it does become an attack target.

The other one is I don't believe tomoyo,ko is going to get built as part of
the fedora/RH infrastructure. Which means module signing will block it. You went
for a "technical" solution on the symbols export, by-passing the community.
What is the next technical solution to get around module signing. Over the top,
paranoid, maybe. Do I think its highly unlikely, yes, but it became a worry as
soon as you pushed this patchset.

>   From module signing perspective, there will be no difference between the LSM
> framework exports LSM hooks and TOMOYO exports LSM hooks. And
> https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp
> leaves the choice available to distro users. Why not acceptable?
> 
> By some chance..., can't module signing prevent any code (both in-tree and
> out-of-tree) that is not signed from loading !?
> 
as long as it goes through the module infrastructure sure.

Powered by blists - more mailing lists