linux-kernel - Re: [PATCH v15 01/11] LSM: Identify modules by more than name

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 16 Sep 2023 15:32:05 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:     Casey Schaufler <casey@...aufler-ca.com>, paul@...l-moore.com,
        linux-security-module@...r.kernel.org
Cc:     jmorris@...ei.org, serge@...lyn.com, keescook@...omium.org,
        john.johansen@...onical.com, stephen.smalley.work@...il.com,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        mic@...ikod.net
Subject: Re: [PATCH v15 01/11] LSM: Identify modules by more than name

On 2023/09/16 2:53, Casey Schaufler wrote:
> I *could* respond with:
> 
> -#define LSM_ID_TOMOYO	103
> 
> but I won't. I won't make a difference because TOMOYO doesn't present
> any attributes. I understand your objections, but don't believe that
> they can't be worked around. The argument that a LSM ID will prevent
> new LSM development is rebuffed by the exact same situation with system
> calls, PRCTL and IOCTL values. The argument that it somehow prevents
> out-of-tree modules falls on deaf ears. The argument that it prevents
> dynamic security modules is subsumed by the other issues surrounding
> dynamic security modules, and does nothing to decrease the likelihood
> of that facility going upstream. Especially since, to the best of my
> knowledge, no one is working on it.

+/**
+ * struct lsm_id - Identify a Linux Security Module.
+ * @lsm: name of the LSM, must be approved by the LSM maintainers

Why can't you understand that "approved by the LSM maintainers" is a horrible
requirement for LSM modules which cannot become one of in-tree LSMs?

One of reasons for not every proposed LSM module can become in-tree is out of
the LSM community's resources for reviewing/maintaining (or failure to acquire
attention from the LSM community enough to get reviewed).

+ * @id: LSM ID number from uapi/linux/lsm.h

Since the LSM community cannot accept all of proposed LSMs due to limited resources,
the LSM community is responsible for allowing whatever proposed LSMs (effectively any
publicly available LSMs) to live as out-of-tree LSMs, by approving the LSM name and
assigning a permanent LSM ID number.

The only exception the LSM community can refuse to approve/assign would be that the name
is not appropriate (e.g. a LSM module named "FuckYou") or the name is misleading (e.g.
"selinux+", "smock", "tomato", "apparmour"). Otherwise, no matter how many times you repeat
"we don't care out-of-tree LSMs" or "I do not intentionally plan to make life difficult for
the out-of-tree LSMs", this patch is intended to lock out out-of-tree LSMs.

+ *
+ * Contains the information that identifies the LSM.
+ */
+struct lsm_id {
+	const char	*name;
+	u64		id;
+};

Therefore, unless you change the policy for assigning LSM ID, I keep NACK on this change.