Re: [PATCH v1 2/8] LSM: Add an LSM identifier for external use
From: Paul Moore <paul@paul-moore.com>
Date: 2022-11-09 23:34:07
Also in:
linux-security-module, lkml
Possibly related (same subject, not in this thread)
- 2022-11-23 · [PATCH v1 2/8] LSM: Add an LSM identifier for external use · Casey Schaufler <casey@schaufler-ca.com>
On Tue, Oct 25, 2022 at 2:45 PM Casey Schaufler [off-list ref] wrote:
Add an integer member "id" to the struct lsm_id. This value is a unique identifier associated with each security module. The values are defined in a new UAPI header file. 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. The first 32 values (0 - 31) are reserved for some as yet unknown but important use. Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> --- include/linux/lsm_hooks.h | 1 + include/uapi/linux/lsm.h | 32 ++++++++++++++++++++++++++++++++ security/apparmor/lsm.c | 2 ++ security/bpf/hooks.c | 2 ++ security/commoncap.c | 2 ++ security/landlock/setup.c | 2 ++ security/loadpin/loadpin.c | 2 ++ security/lockdown/lockdown.c | 2 ++ security/safesetid/lsm.c | 2 ++ security/selinux/hooks.c | 2 ++ security/smack/smack_lsm.c | 2 ++ security/tomoyo/tomoyo.c | 2 ++ security/yama/yama_lsm.c | 2 ++ 13 files changed, 55 insertions(+) create mode 100644 include/uapi/linux/lsm.h
Unless you're getting paid by the patch, I'd rather you combine patches 1/8 and 2/8 into a single patch. They are both pretty small, very related, and I don't want to see 1/8 merged anywhere without 2/8.
quoted hunk ↗ jump to hunk
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index e383e468f742..dd4b4d95a172 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h@@ -1607,6 +1607,7 @@ struct security_hook_heads { */ struct lsm_id { const char *lsm; /* Name of the LSM */ + int id; /* LSM ID */ };
At the very least let's define lsm_id::id as an 'unsigned int' type, but since we are going to see the lsm_id::id token used as part of the kernel ABI (likely not in this struct) I agree with Greg's comments about making the size more explicit. I would suggest __u32/u32 as 32-bits should be plenty for this token. Given the other upstream discussions we may want to do something similar with lsm_id::lsm and __u8/u8. I'm pretty sure I saw a similar comment (by Greg?) elsewhere in this patchset when I was quickly skimming these on my phone while away ... -- paul-moore.com