On Fri, Nov 25, 2022 at 11:30 AM Mickaël Salaün [off-list ref] wrote:

On 23/11/2022 21:15, Casey Schaufler wrote:

quoted

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.

Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
---
  include/linux/lsm_hooks.h    | 16 ++++++++++++++--
  include/uapi/linux/lsm.h     | 32 ++++++++++++++++++++++++++++++++
  security/apparmor/lsm.c      |  8 +++++++-
  security/bpf/hooks.c         | 13 ++++++++++++-
  security/commoncap.c         |  8 +++++++-
  security/landlock/cred.c     |  2 +-
  security/landlock/fs.c       |  2 +-
  security/landlock/ptrace.c   |  2 +-
  security/landlock/setup.c    |  6 ++++++
  security/landlock/setup.h    |  1 +
  security/loadpin/loadpin.c   |  9 ++++++++-
  security/lockdown/lockdown.c |  8 +++++++-
  security/safesetid/lsm.c     |  9 ++++++++-
  security/security.c          | 12 ++++++------
  security/selinux/hooks.c     |  9 ++++++++-
  security/smack/smack_lsm.c   |  8 +++++++-
  security/tomoyo/tomoyo.c     |  9 ++++++++-
  security/yama/yama_lsm.c     |  8 +++++++-
  18 files changed, 141 insertions(+), 21 deletions(-)
  create mode 100644 include/uapi/linux/lsm.h

...

quoted

diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
new file mode 100644
index 000000000000..47791c330cbf
--- /dev/null
+++ b/include/uapi/linux/lsm.h

@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Linux Security Modules (LSM) - User space API
+ *
+ * Copyright (C) 2022 Casey Schaufler <casey@schaufler-ca.com>
+ * Copyright (C) 2022 Intel Corporation
+ */
+
+#ifndef _UAPI_LINUX_LSM_H
+#define _UAPI_LINUX_LSM_H
+
+/*
+ * ID values to identify security modules.
+ * A system may use more than one security module.
+ *
+ * Values 1-99 are reserved for future use in special cases.

This line should be removed unless justified. What could be special
about IDs? The syscalls already have a "flags" argument, which is enough.

quoted

+ */
+#define LSM_ID_INVALID               0

Reserving 0 is good, but it doesn't deserve a dedicated declaration.
LSM_ID_INVALID should be removed.

quoted

+#define LSM_ID_CAPABILITY    100

This should be 1…

No.  Scratch that, make that an emphatic "No".

If you want to argue for a different reserved low-number range, e.g.
something with a nice power-of-2 limit, I'm okay with that, but as I
wrote earlier I feel strongly we need to have a low-number reserved
range for potential future uses.

-- 
paul-moore.com