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: <9387e6bb-484a-443d-ad87-24cf6e976e61@I-love.SAKURA.ne.jp>
Date: Thu, 3 Oct 2024 08:09:13 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: 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/02 23:01, Paul Moore wrote:
>> Now that built-in LSM modules started using __ro_after_init static calls, !built-in
>> LSM modules can start using !__ro_after_init linked list without affecting built-in
>> LSM modules. I can't understand why Paul does not like it.
> 
> A *lot* of effort has gone into both hardening and improving the
> performance of the LSM framework.  I'm loath to introduce anything
> which would take away from those gains, especially if it is only done
> to satisfy out-of-tree LSMs, or users who don't agree with their
> distro kernel's build-time configuration.

Forcing distro users to rebuild distro kernels (with or without modified
kernel configurations) is no longer a viable solution.

Since cryptography (e.g. module signing keys) is getting used inside kernels,
noone except the one who has the private key and has built the original kernel
can reproduce the same behavior/functionality (even without modified kernel
configurations). Also, from package management perspective, users get confused
by being forced to use different package names/versions (when installing kernel
related packages) and breaking package dependency (when installing userspace
packages). You said

  Comparing userspace applications to kernel code isn't a fair
  comparison as a userspace application can generally be added without
  impacting the other applications on the system.

  Anyone is always free to build their own kernel with whatever code
  changes they like, this is the beauty of the kernel source being
  available and licensed as Open Source.  You are free to build a kernel
  with whatever LSM you like included and enabled.  You have been shown
  examples on how to do this in previous threads.

at https://lkml.kernel.org/r/CAHC9VhQq0-D=p9Kicx2UsDrK2NJQDyn9psL-PWojAA+Y17WiFQ@mail.gmail.com .
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).