Paul Moore, 14 Sep 2024:

On Fri, Sep 13, 2024 at 4:49 PM Konstantin Andreev [off-list ref] wrote:

quoted

Casey Schaufler, 10 Sep 2024:

quoted

...
The lsm_prop structure definition is intended to keep the LSM
specific information private to the individual security modules.
...
index 1390f1efb4f0..1027c802cc8c 100644

--- a/include/linux/security.h
+++ b/include/linux/security.h

@@ -140,6 +144,22 @@ enum lockdown_reason {
+
+/*
+ * Data exported by the security modules
+ */
+struct lsm_prop {
+     struct lsm_prop_selinux selinux;
+     struct lsm_prop_smack smack;
+     struct lsm_prop_apparmor apparmor;
+     struct lsm_prop_bpf bpf;
+     struct lsm_prop_scaffold scaffold;
+};

This design prevents compiling and loading out-of-tree 3rd party LSM, am I right?

Out-of-tree LSM's were discussed recently at

https://lore.kernel.org/linux-security-module/efb8f264-f80e-43b2-8ea3-fcc9789520ec@I-love.SAKURA.ne.jp/T/ (local)
https://lore.kernel.org/linux-security-module/960e740f-e5d9-409b-bb2a-8bdceffaae95@I-love.SAKURA.ne.jp/T/ (local)

but it looks like a final decision to ban them is not taken yet.

For those who haven't read my latest comment in the v6.12 merge window
pull request, I'll copy-n-paste it here:

I have certainly seen your comment,

"My focus is on the upstream Linux kernel and ensuring that the
upstream, in-tree LSMs have the best framework possible to ensure
their proper operation and ease of development/maintenance.  While I
have no intention to negatively impact out-of-tree LSMs, I will not
harm the upstream code base solely to support out-of-tree LSMs.
Further, if improvements to the upstream LSM framework are determined
to harm out-of-tree LSMs, that shall be no reason to reject the
upstream improvements.  I believe this policy is not only consistent
with that of previous LSM maintainers, but of the general Linux kernel
as well."

but the matter of fact is … your dispute with Tetsuo Handa still continues.
You are sending controversal signals to the public.
--
Konstantin Andreev