On Fri, Nov 25, 2022 at 11:30 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > On 23/11/2022 21:15, 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. > > > > Signed-off-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> > > --- > > 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 ... > > 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@xxxxxxxxxxxxxxxx> > > + * 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. > > > + */ > > +#define LSM_ID_INVALID 0 > > Reserving 0 is good, but it doesn't deserve a dedicated declaration. > LSM_ID_INVALID should be removed. > > > > +#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
