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@xxxxxxxxxxxxxxxx> >> Cc: linux-security-module <linux-security-module@xxxxxxxxxxxxxxx> >> Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> >> Reviewed-by: Serge Hallyn <serge@xxxxxxxxxx> >> Reviewed-by: Mickael Salaun <mic@xxxxxxxxxxx> >> Reviewed-by: John Johansen <john.johansen@xxxxxxxxxxxxx> > Nacked-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx >
