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

From: Casey Schaufler <casey@schaufler-ca.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	paul@paul-moore.com, linux-security-module@vger.kernel.org
Cc: jmorris@namei.org, serge@hallyn.com, keescook@chromium.org,
	john.johansen@canonical.com, stephen.smalley.work@gmail.com,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	mic@digikod.net, Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH v15 01/11] LSM: Identify modules by more than name
Date: Fri, 15 Sep 2023 10:53:54 -0700	[thread overview]
Message-ID: <568c0730-b458-04b4-dbfa-77da1758aa05@schaufler-ca.com> (raw)
In-Reply-To: <1f5e725d-58b6-eca2-97dc-d7c1209ff167@I-love.SAKURA.ne.jp>

On 9/15/2023 4:32 AM, Tetsuo Handa wrote:
> On 2023/09/13 5:56, Casey Schaufler wrote:
>> Create a struct lsm_id to contain identifying information about Linux
>> Security Modules (LSMs). At inception this contains the name of the
>> module and an identifier associated with the security module.  Change
>> the security_add_hooks() interface to use this structure.  Change the
>> individual modules to maintain their own struct lsm_id and pass it to
>> security_add_hooks().
>>
>> The values are for LSM identifiers are defined in a new UAPI
>> header file linux/lsm.h. Each existing LSM has been updated to
>> include it's LSMID in the lsm_id.
>>
>> The LSM ID values are sequential, with the oldest module
>> LSM_ID_CAPABILITY being the lowest value and the existing modules
>> numbered in the order they were included in the main line kernel.
>> This is an arbitrary convention for assigning the values, but
>> none better presents itself. The value 0 is defined as being invalid.
>> The values 1-99 are reserved for any special case uses which may
>> arise in the future. This may include attributes of the LSM
>> infrastructure itself, possibly related to namespacing or network
>> attribute management. A special range is identified for such attributes
>> to help reduce confusion for developers unfamiliar with LSMs.
>>
>> LSM attribute values are defined for the attributes presented by
>> modules that are available today. As with the LSM IDs, The value 0
>> is defined as being invalid. The values 1-99 are reserved for any
>> special case uses which may arise in the future.
>>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>> Cc: linux-security-module <linux-security-module@vger.kernel.org>
>> Reviewed-by: Kees Cook <keescook@chromium.org>
>> Reviewed-by: Serge Hallyn <serge@hallyn.com>
>> Reviewed-by: Mickael Salaun <mic@digikod.net>
>> Reviewed-by: John Johansen <john.johansen@canonical.com>
> Nacked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

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.

> https://lkml.kernel.org/r/4a6b6e2c-9872-4d4c-e42e-4ff0fb79f3ae@I-love.SAKURA.ne.jp
>