linux-kernel - Re: [PATCH] LSM: allow loadable kernel module based LSM modules

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: <d16cd3d1-4b32-487e-b116-419c19941472@I-love.SAKURA.ne.jp>
Date: Fri, 6 Sep 2024 16:43:15 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Paul Moore <paul@...l-moore.com>
Cc: linux-security-module <linux-security-module@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, tomoyo-dev-en@...ts.osdn.me,
        tomoyo-users-en@...ts.osdn.me,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] LSM: allow loadable kernel module based LSM modules

On 2024/09/04 23:23, Paul Moore wrote:
> On Wed, Sep 4, 2024 at 3:10 AM Tetsuo Handa
> <penguin-kernel@...ove.sakura.ne.jp> wrote:
>>
>> Until 2.6.23, it was officially possible to register/unregister LSM modules
>> that are implemented as loadable kernel modules.
> 
> ...
> 
>> Paul Moore has commented
>>
>>   I do not intentionally plan to make life difficult for the out-of-tree
>>   LSMs, but if that happens as a result of design decisions intended to
>>   benefit in-tree LSMs that is acceptable as far as I am concerned.
> 
> Patches that add complexity to the LSM framework without any benefit
> to the upstream, in-tree LSMs, or the upstream kernel in general, are
> not good candidates for inclusion in the upstream kernel.
> 

The idea and implementation for using LSM from loadable kernel modules is what
I demonstrated you in a lightening talk session in LinuxCon North America 2010.
It is 14 years since we learned my concern, and you had been ignoring my concern
until now.

The first solution is "do not use static calls". But you won't agree it. Also,
I'm not against use of static calls as long as LKM-based LSM is supported.

The second solution is "export static calls" (and leave how it is used by
LKM-based LSMs). But some of LSM people do not like solutions that can allow
LKMs to disable built-in LSMs.

The third solution is "continue using linked list for LKM-based LSMs" which was
suggested by KP Singh [1]. I'm OK with this solution, though it is unlucky that
LKM-based LSMs can't be benefited from "static calls".

If you ignore my concern, I have to NACK the static call changes you are
going to send in the upcoming merge window.

Link: https://lkml.kernel.org/r/CACYkzJ7ght66802wQFKzokfJKMKDOobYgeaCpu5Gx=iX0EuJVg@mail.gmail.com [1]