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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cd548445-777c-46d7-abe3-de8e06e509ee@I-love.SAKURA.ne.jp>
Date: Thu, 3 Oct 2024 15:16:06 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: John Johansen <john.johansen@...onical.com>,
        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 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?
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...

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

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

 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 !?