linux-kernel - Re: [GIT PULL] lsm/lsm-pr-20240911

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 for Android: free password hash cracker in your pocket

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

Message-ID: <960e740f-e5d9-409b-bb2a-8bdceffaae95@I-love.SAKURA.ne.jp>
Date: Fri, 13 Sep 2024 21:28:52 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Paul Moore <paul@...l-moore.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] lsm/lsm-pr-20240911

On 2024/09/13 10:29, Paul Moore wrote:
> Linus,
> 
> We've got a reasonably large pull request for the LSM framework this
> time (at least it's large for us), here are the highlights:
> 
> * Move the LSM framework to static calls
> 
> Based on some of our exchanges over the summer, it sounds like you
> are already familiar with the effort to convert the LSM callbacks
> from function pointers to static calls.  This pull request includes
> that work and transitions the vast majority of the LSM callbacks into
> static calls.  Those callbacks which haven't been converted were
> left as-is due to the general ugliness of the changes required to
> support the static call conversion; we can revisit those callbacks
> at a future date.
> 
> It is worth mentioning that Tetsuo Handa is opposed to the static call
> patches, some even carry his NACK, as they make it more difficult to
> dynamically load out-of-tree LSMs, or unsupported LSMs on distro kernels.
> Many of us have tried to explain that out-of-tree LSMs are not a
> concern for the upstream LSM framework, or the Linux kernel in general,
> and that decisions around what LSMs are enabled in distro kernels is
> a distro issue, not an upstream issue, but unfortunately Tetsuo
> continues to disregard these arguments.

No, this is not only a distro issue but also an upstream issue!
Because the upstream cannot afford accepting whatever proposed LSMs
( https://lkml.kernel.org/r/8ac2731c-a1db-df7b-3690-dac2b371e431@I-love.SAKURA.ne.jp ).
That is, out-of-tree LSMs cannot become in-tree and obtain stable LSM ID is
partially due to upstream (e.g. out of resources for review, or failure to
pass patent examination because upstream does not think it adds a new value).
Making out-of-tree (or in-tree but not built-in) LSMs harder to use is a
penalty imposed by "Permanent members are exercising veto".
At least, assigning stable LSM ID to whatever proposed LSM has absolutely
zero cost. Current policy is a clear intention to lock out out-of-tree LSMs.
If you say "I don't have intention to lock out out-of-tree LSMs", please
don't go with just NACK added.