ANN: new LSM guidelines

[Tetsuo Handa]

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

If you worry about cluttering/depleting the LSM ID space, don't assign
64 bits for LSM ID; the LSM community won't accept 100+ LSMs for in-tree.

+/**
+ * struct lsm_id - Identify a Linux Security Module.
+ * @lsm: name of the LSM, must be approved by the LSM maintainers
+ * @id: LSM ID number from uapi/linux/lsm.h
+ *
+ * Contains the information that identifies the LSM.
+ */
+struct lsm_id {
+	const char	*name;
+	u64		id;
+};

Developers will more likely to abuse LSM ID (as if randomly generated GUID, or
something like 0xdeadbeef) if the LSM community does not allow out-of-tree
LSM modules to have a persistent registration. Once some value is assigned and
published via a publicly available git repository by the LSM module author,
the merit of "LSM: Identify modules by more than name" will be lost.

> 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 don't care if out-of-tree code encounters build failures like
https://sourceware.org/bugzilla/show_bug.cgi?id=30831 due to changing
in-kernel APIs. That's what remaining out-of-tree means. But they have
the rights/freedom to fix and load and run their code using their resources.

In-tree Linux kernel developers do not prevent out-of-tree Linux kernel
developers from loading and running their out-of-tree code. I absolutely
resist if out-of-tree code encounters loss of ability to load and run
that code (e.g. sys_init_module() prevents out-of-tree modules from
loading because your priority of out-of-tree modules is the lowest).

Although LKM-based LSM modules are not currently supported, people have
the rights/freedom to load and run out-of-tree LSM modules by rebuilding
their kernels.

Those who develop a kernel module have rights/freedom to give any name.
But as a whole, developers try to avoid identifier collisions.

You are intentionally making life difficult for the out-of-tree LSMs, by
requiring an LSM ID (and facilitating LSM ID collisions). No matter how
priority of out-of-tree LSMs is low for you, what you are about to merge
goes against the "developers try to avoid identifier collisions" effort.

Introducing a numeric identifier is a good opportunity for permanently
eliminating possibility of identifier collisions. But current usage of this
numeric identifier is designed for facilitating possibility of identifier
collisions.