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: <8114a37e-1306-47ee-b27e-a61c1c7bca94@I-love.SAKURA.ne.jp>
Date: Thu, 3 Oct 2024 13:26:26 +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 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).