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] [day] [month] [year] [list]

Message-ID: <19e29693-718c-4667-ab40-948718bcc6f5@I-love.SAKURA.ne.jp>
Date: Wed, 2 Oct 2024 12:31:54 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Paul Moore <paul@...l-moore.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc: 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 1:36, Linus Torvalds wrote:
>> Linus, it's unclear if you're still following this thread after the
>> pull, but can you provide a little insight on your thoughts here?

Yes, I want to hear what Linus thinks.

> I absolutely hate the whole "security people keep arguing", and I
> cannot personally find it in myself to care about tomoyo.  I don't
> even know where it is used - certainly not in Fedora, which is the
> only distro I can check quickly.

As far as I am aware, TOMOYO is enabled in Ubuntu, Debian and openSUSE kernels.
CentOS plus (which provides additional functionality over RHEL, but was killed
by CentOS Stream) kernels also enabled TOMOYO. But not yet in Fedora kernels.

> If the consensus is that we should revert, I'll happily revert. This
> was all inside of the tomoyo subdirectory, so I didn't see it as some
> kind of sidestepping, and treated the pull request as a regular
> "another odd security subsystem update".

I will revert TOMOYO changes if Paul succeeds in getting rid of
CONFIG_MODULES=y support from the upstream kernel. ;-)

On 2024/10/02 3:22, Paul Moore wrote:
> Starting tomorrow when I'm reliably back in front of computer I'll
> sort this out with the rest of the LSM folks.  Unless something
> unexpected comes up in the discussion I'll send you a revert later
> this week.

What I am asking LSM framework is as simple as
https://lkml.kernel.org/r/caafb609-8bef-4840-a080-81537356fc60@I-love.SAKURA.ne.jp .

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.

> Yes, that's fair, I think you would need a deeper understanding of the
> LSM framework as well as an understanding of recent discussions on the
> list to appreciate all of the details.

Yes, please. How strange recent discussions about LSM framework is. :-(