ANN: new LSM guidelines

[Paul Moore]

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.

> 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.

-- 
paul-moore.com