ANN: new LSM guidelines

[Tetsuo Handa]

On 2023/09/25 10:32, Kees Cook wrote:
> On Mon, Sep 25, 2023 at 09:55:47AM +0900, Tetsuo Handa wrote:
>> On 2023/09/13 4:00, Paul Moore wrote:
>>> On Tue, Sep 12, 2023 at 2:40 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>> On 9/12/2023 11:08 AM, Paul Moore wrote:
>>>>>
>>>>> Once again, we've already discussed this many, many times: out-of-tree
>>>>> LSMs are not the priority and that is not going to change.  One
>>>>> corollary of this is that we are not going to assign LSM IDs to LSMs
>>>>> that remain out-of-tree as this would negatively impact the LSM layer
>>>>> by cluttering/depleting the LSM ID space.
>>
>> Like Kees Cook said, we don't need to worry about depleting the LSM ID space
>> because lsm_id::id is a u64. We only need to worry about cluttering/conflicting
>> the values.
> 
> Right, this will go one of two ways:
> 
> 1) author: "Hello, here is a new LSM I'd like to upstream, here it is. I assigned
>             it the next LSM ID."
>    maintainer(s): "Okay, sounds good. *review*"
> 
> 2) author: "Hello, here is an LSM that has been in active use at $Place,
>             and we have $Xxx many userspace applications that we cannot easily
>             rebuild. We used LSM ID $Value that is far away from the sequential
>             list of LSM IDs, and we'd really prefer to keep that assignment."
>   maintainer(s): "Okay, sounds good. *review*"
> 
> No problems detected.

No problem if what you wrote above is the policy. What is important is that the assigned
LSM ID value remains available for that LSM. "Okay, sounds good." has to be the only
requirement for assigning long-term persistent registrations. Whether that LSM succeeds
to become in-tree must be irrelevant for assigning permanently available LSM ID value.

It is not clear whether the proposed LSM ID value is added to include/uapi/linux/lsm.h file
of the upstream Linux kernel (it is required for avoid cluttering/conflicting) before
the LSM module which wants to use that LSM ID value succeeds to become in-tree.

But if LSM ID serves as an index for what LSMs are available in the world,
by maintaining "the LSM module name, the LSM ID value, short description about
that LSM module, the public git repository or web site for more information
about that LSM module" pairs (e.g. somewhere in the LSM community's Wiki rather than
in include/uapi/linux/lsm.h ), people can easily find what LSMs could be used
for their purpose, and developers can avoid re-inventing similar LSM modules
which are already available somewhere in the world.

That's what I said

  Since the LSM community cannot accept all of proposed LSMs due to limited resources,
  the LSM community is responsible for allowing whatever proposed LSMs (effectively any
  publicly available LSMs) to live as out-of-tree LSMs, by approving the LSM name and
  assigning a permanent LSM ID number.

in https://lkml.kernel.org/r/94743c22-bc76-e741-e577-3e0845423f69@I-love.SAKURA.ne.jp .

Casey and Paul, do you agree to change your policy for assigning LSM ID ?