ANN: new LSM guidelines

[Tetsuo Handa]

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.

>>>                                            LSMs that are working
>>> towards integration with the upstream Linux kernel can self-assign a
>>> temporary LSM ID which will be finalized upon merging in the LSM tree.

A review might take years (like we did with the pathname based access control
in the past). What userspace would want to use of long-term non-persistent
registrations? At the stage of publishing an LSM (and userspace tools which
make use of LSM ID value), the LSM ID value should be long-term persistent
registrations. Recompiling userspace tools every time is no good.

>>> Based on all of the arguments you have already submitted - and let us
>>> be very clear: you are the only one speaking out against this - I see
>>> no reason to change this policy.
>>
>> I won't say this is a great idea, or that I endorse it, but we could
>> allocate a range of LSM ID values ( 10000 - 10999 ? ) that we promise
>> will never be given to an upstream LSM. We wouldn't make any guarantees
>> about conflicts otherwise. These could be used by LSMs before they are
>> accepted upstream or by LSMs that don't have upstream aspirations. I
>> seriously doubt that anyone using such an LSM is going to be mixing
>> multiple such LSMs without being capable of managing ID conflicts.
> 
> Not a crazy idea.  I had debated something similar, a reserved
> "private use" or "experimentation" range; there is definitely
> precedence for that in other areas, e.g. network protocols.  What held
> me back is that invariably folks will want to create long-term
> persistent registrations against this space for their out-of-tree LSMs
> which would require some sort of unofficial, adhoc registration
> authority which starts to get a bit silly in my opinion (the
> registration authority for the Linux kernel API is the upstream Linux
> kernel community).

Not silly at all. I do want to create long-term persistent registrations
against this space for any publicly available LSMs.

The sane and the better usage of LSM ID is to register any publicly available
LSMs. 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, 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 (and optionally helps
avoiding module name collisions with any publicly available LSMs).

> 
> Temporary assignments while a LSM is undergoing the review-revision
> cycle on its way to being merged is something different and if we need
> a couple of reserved numbers for that (one or two MAX) we can consider
> that, but I don't expect this to be a major problem in practice.  LSMs
> that are in this transient pre-merge state shouldn't be used for
> production purposes and thus a LSM ID change on merging shouldn't be a
> problem.

It is possible that more than 3 LSMs concurrently get under the review;
reserving 2 at most can deplete the reserved LSM ID space.

No userspace tools want to recompile due to unstable LSM ID values.
Temporary assignments is no good.