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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ