ANN: new LSM guidelines

[Tetsuo Handa]

On 2023/08/03 7:00, Paul Moore wrote:
> * 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.

s/work/burden/ ?

> * Any userspace tools or patches created in support of the LSM must be publicly
> available, with a public git repository preferable over a tarball snapshot.

What is the definition of "publicly" here? Everyone can download related resources
including the source code etc. anonymously (e.g. without asking for creating user
account and/or buying subscriptions ) ?



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 ?

This might trigger a catch-22 situation while reviewing, for the author of such
userspace tools will not be able to publish on a publicly available git repository
without the stable LSM ID whereas LSM people say that only in-tree LSMs get the
stable LSM ID. If userspace tools needs to be publicly available while reviewing,
a stable LSM ID must be assigned for that LSM in order to allow userspace tools
being published on a publicly available git repository by the moment the author
of a new LSM proposes that LSM to the community for review.

I'm still against the "only in-tree LSMs get the stable LSM ID" part. As long as
someone developed an LSM in a manner that is publicly available, a stable LSM ID
should be assigned, regardless of whether that LSM succeeds in becoming one of
in-tree LSMs.