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

[Tetsuo Handa]

On 2023/09/21 0:08, Kees Cook wrote:
> I feel like you are willfully not listening to us when we say that this
> doesn't block out of tree LSMs. Again, there is nothing here that stops
> it. To prove this point, here is an out of tree LSM that works with this
> series. So let's move from theoretical to practical: given this example,
> why do you think out of tree LSMs are blocked?

Because an LSM ID value

> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
> index eeda59a77c02..23b7a8f79cef 100644
> --- a/include/uapi/linux/lsm.h
> +++ b/include/uapi/linux/lsm.h
> @@ -63,6 +63,8 @@ struct lsm_ctx {
>  #define LSM_ID_BPF		110
>  #define LSM_ID_LANDLOCK		111
>  
> +#define LSM_ID_GOAT		1138
> +
>  /*
>   * LSM_ATTR_XXX definitions identify different LSM attributes
>   * which are used in the kernel's LSM userspace API. Support

is assigned to LSM only when that LSM became no longer out of tree.

I'm against the policy that only LSM modules that succeeded to become
in-tree are assigned LSM ID. That's not a good usage of identifier.

Quoting from https://lkml.kernel.org/r/4a6b6e2c-9872-4d4c-e42e-4ff0fb79f3ae@xxxxxxxxxxxxxxxxxxx :

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

You must not say "We don't care about out of tree LSMs." when talking about this patch.