ANN: new LSM guidelines

[Casey Schaufler]

On 9/12/2023 11:08 AM, Paul Moore wrote:
> On Mon, Sep 11, 2023 at 9:29 PM Tetsuo Handa
> <penguin-kernel at i-love.sakura.ne.jp> wrote:
>> On 2023/09/12 5:04, Paul Moore wrote:
>>>> If one of userspace tools designed for the new LSM depends on the LSM ID, when can
>>>> the author of the new LSM obtain the stable LSM ID for that LSM ?
>>> A permanent LSM ID is assigned to LSMs when they are merged into the
>>> upstream LSM tree.  This is no different than any other kernel defined
>>> macro constant, enum, magic number, etc. that is shared between kernel
>>> and userspace and is considered part of the kernel's API.
>> Then, your
>>
>>   * The new LSM must be sufficiently unique to justify the additional work
>>   involved in reviewing, maintaining, and supporting the LSM.  It is reasonable
>>   for there to be a level of overlap between LSMs, but either the security model
>>   or the admin/user experience must be significantly unique.
>>
>> is an ultimately unfair requirement, for the combination of
>>
>>   Ultimately, new LSMs are added to the kernel at the discretion of the maintainers
>>   and reviewers.
>>
>> and
>>
>>   A permanent LSM ID is assigned to LSMs when they are merged into the upstream
>>   LSM tree.
>>
>> causes locking out not-yet-in-tree and out-of-tree LSMs.
> As discussed many times prior, I consider in-tree, upstreamed LSMs my
> priority when it comes to decision making.  LSMs which are under
> development and are working to be merged come next, and LSMs which
> have decided to remain out-of-tree remain last.  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.  You
> are free to disagree, but I believe the policy I've described here is
> consistent with the bulk of the other kernel subsystems and I have no
> plans to change this policy.
>
>>> I understand you are opposed to the numeric LSM ID as part of the
>>> kernel's API, but I believe this is both the correct way forward, and
>>> consistent with other kernel APIs.  It is your right to disagree, but
>>> I have yet to see a reason to revisit this decision and respectfully
>>> request that you accept this and refrain from revisiting this argument
>>> unless you have new information which would warrant a new discussion.
>> I'm not against the numeric LSM ID itself. I'm against the policy for assigning
>> numeric LSM ID. The numeric LSM ID can become the correct way forward only if
>> the following problem is solved.
>>
>> A market is not a location where only products that passed a patent examination
>> are available ...
> 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.  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.
> 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.

Just a thought.

>> The LSM ID is not a API. The LSM ID is a publicly available database.
> By every definition of "API" that I have ever seen, the LSM ID *is*
> part of the proposed LSM syscall API.
>
> In my last email in this thread I asked you to refrain from revisiting
> old arguments.  Unfortunately you either chose to reject that request
> or you mistakenly thought your latest email was presenting new ideas
> as opposed to a slight reframing of your existing objections.  I am
> sorry that we have reached this point, but I am done discussing this
> with you Tetsuo; unless I see any new arguments from you this will be
> my last reply to you on this topic.
>