Add two system calls for the Linux Security Module ABI.
lsm_self_attr() provides the security module specific attributes
that have previously been visible in the /proc/self/attr directory.
For each attribute that is set on the current process the system
call will return an LSM identifier, an attribute identifier and
the value of the attribute. The LSM and attribute identifier values
are defined in include/uapi/linux/lsm.h
lsm_module_list() provides the LSM identifiers, in order, of the
security modules that are active on the system. This has been
available in the securityfs file /sys/kernel/security/lsm.
Patch 0001 changes the LSM registration from passing the name
of the module to passing a lsm_id structure that contains the
name of the module.
Patch 0002 adds an LSM identifier number to the lsm_id structure.
Patch 0003 adds an attribute identifier to the lsm_id.
Patch 0004 adds the registered lsm_ids to a table.
Patch 0005 changes security_[gs]etprocattr() to use LSM IDs instead
of LSM names.
Patch 0006 implements lsm_self_attr().
Patch 0007 implements lsm_module_list().
Patch 0008 wires up the two syscalls.
Casey Schaufler (8):
LSM: Identify modules by more than name
LSM: Add an LSM identifier for external use
LSM: Identify the process attributes for each module
LSM: Maintain a table of LSM attribute data
proc: Use lsmids instead of lsm names for attrs
LSM: lsm_self_attr syscall for LSM self attributes
LSM: Create lsm_module_list system call
lsm: wireup syscalls lsm_self_attr and lsm_module_list
arch/alpha/kernel/syscalls/syscall.tbl | 2 +
arch/arm/tools/syscall.tbl | 2 +
arch/arm64/include/asm/unistd32.h | 2 +
arch/ia64/kernel/syscalls/syscall.tbl | 2 +
arch/m68k/kernel/syscalls/syscall.tbl | 2 +
arch/microblaze/kernel/syscalls/syscall.tbl | 2 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 2 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 2 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 2 +
arch/parisc/kernel/syscalls/syscall.tbl | 2 +
arch/powerpc/kernel/syscalls/syscall.tbl | 2 +
arch/s390/kernel/syscalls/syscall.tbl | 2 +
arch/sh/kernel/syscalls/syscall.tbl | 2 +
arch/sparc/kernel/syscalls/syscall.tbl | 2 +
arch/x86/entry/syscalls/syscall_32.tbl | 2 +
arch/x86/entry/syscalls/syscall_64.tbl | 2 +
arch/xtensa/kernel/syscalls/syscall.tbl | 2 +
fs/proc/base.c | 29 +--
fs/proc/internal.h | 2 +-
include/linux/lsm_hooks.h | 13 +-
include/linux/security.h | 28 ++-
include/linux/syscalls.h | 3 +
include/uapi/asm-generic/unistd.h | 5 +-
include/uapi/linux/lsm.h | 67 ++++++
kernel/sys_ni.c | 4 +
security/Makefile | 1 +
security/apparmor/lsm.c | 9 +-
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/lsm_syscalls.c | 194 ++++++++++++++++++
security/safesetid/lsm.c | 9 +-
security/security.c | 37 +++-
security/selinux/hooks.c | 11 +-
security/smack/smack_lsm.c | 9 +-
security/tomoyo/tomoyo.c | 9 +-
security/yama/yama_lsm.c | 8 +-
.../arch/mips/entry/syscalls/syscall_n64.tbl | 2 +
.../arch/powerpc/entry/syscalls/syscall.tbl | 2 +
.../perf/arch/s390/entry/syscalls/syscall.tbl | 2 +
.../arch/x86/entry/syscalls/syscall_64.tbl | 2 +
47 files changed, 484 insertions(+), 47 deletions(-)
create mode 100644 include/uapi/linux/lsm.h
create mode 100644 security/lsm_syscalls.c
base-commit: 247f34f7b80357943234f93f247a1ae6b6c3a740
--
2.37.3
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 <[email protected]>
---
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
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 */
};
/*
diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
new file mode 100644
index 000000000000..d5bcbb9375df
--- /dev/null
+++ b/include/uapi/linux/lsm.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Linus Security Modules (LSM) - User space API
+ *
+ * Copyright (C) 2022 Casey Schaufler <[email protected]>
+ * Copyright (C) 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.
+ *
+ * LSM_ID_XXX values 0 - 31 are reserved for future use
+ */
+#define LSM_ID_INVALID -1
+#define LSM_ID_CAPABILITY 32
+#define LSM_ID_SELINUX 33
+#define LSM_ID_SMACK 34
+#define LSM_ID_TOMOYO 35
+#define LSM_ID_IMA 36
+#define LSM_ID_APPARMOR 37
+#define LSM_ID_YAMA 38
+#define LSM_ID_LOADPIN 39
+#define LSM_ID_SAFESETID 40
+#define LSM_ID_LOCKDOWN 41
+#define LSM_ID_BPF 42
+#define LSM_ID_LANDLOCK 43
+
+#endif /* _UAPI_LINUX_LSM_H */
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index e708c1ad7267..b859b1af6c75 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -24,6 +24,7 @@
#include <linux/zlib.h>
#include <net/sock.h>
#include <uapi/linux/mount.h>
+#include <uapi/linux/lsm.h>
#include "include/apparmor.h"
#include "include/apparmorfs.h"
@@ -1204,6 +1205,7 @@ struct lsm_blob_sizes apparmor_blob_sizes __lsm_ro_after_init = {
static struct lsm_id apparmor_lsmid __lsm_ro_after_init = {
.lsm = "apparmor",
+ .id = LSM_ID_APPARMOR,
};
static struct security_hook_list apparmor_hooks[] __lsm_ro_after_init = {
diff --git a/security/bpf/hooks.c b/security/bpf/hooks.c
index ef9b1d983665..20983ae8d31f 100644
--- a/security/bpf/hooks.c
+++ b/security/bpf/hooks.c
@@ -5,6 +5,7 @@
*/
#include <linux/lsm_hooks.h>
#include <linux/bpf_lsm.h>
+#include <uapi/linux/lsm.h>
static struct security_hook_list bpf_lsm_hooks[] __lsm_ro_after_init = {
#define LSM_HOOK(RET, DEFAULT, NAME, ...) \
@@ -21,6 +22,7 @@ static struct security_hook_list bpf_lsm_hooks[] __lsm_ro_after_init = {
*/
struct lsm_id bpf_lsmid __lsm_ro_after_init = {
.lsm = "bpf",
+ .id = LSM_ID_BPF,
};
static int __init bpf_lsm_init(void)
diff --git a/security/commoncap.c b/security/commoncap.c
index 986920da0c26..940e36d8503d 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -25,6 +25,7 @@
#include <linux/binfmts.h>
#include <linux/personality.h>
#include <linux/mnt_idmapping.h>
+#include <uapi/linux/lsm.h>
/*
* If a non-root user executes a setuid-root binary in
@@ -1448,6 +1449,7 @@ int cap_mmap_file(struct file *file, unsigned long reqprot,
static struct lsm_id capability_lsmid __lsm_ro_after_init = {
.lsm = "capability",
+ .id = LSM_ID_CAPABILITY,
};
static struct security_hook_list capability_hooks[] __lsm_ro_after_init = {
diff --git a/security/landlock/setup.c b/security/landlock/setup.c
index 4a12666a4090..5b32c087e34b 100644
--- a/security/landlock/setup.c
+++ b/security/landlock/setup.c
@@ -8,6 +8,7 @@
#include <linux/init.h>
#include <linux/lsm_hooks.h>
+#include <uapi/linux/lsm.h>
#include "common.h"
#include "cred.h"
@@ -25,6 +26,7 @@ struct lsm_blob_sizes landlock_blob_sizes __lsm_ro_after_init = {
struct lsm_id landlock_lsmid __lsm_ro_after_init = {
.lsm = LANDLOCK_NAME,
+ .id = LSM_ID_LANDLOCK,
};
static int __init landlock_init(void)
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 24d041a888b8..32bdf7294a6f 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -20,6 +20,7 @@
#include <linux/string_helpers.h>
#include <linux/dm-verity-loadpin.h>
#include <uapi/linux/loadpin.h>
+#include <uapi/linux/lsm.h>
#define VERITY_DIGEST_FILE_HEADER "# LOADPIN_TRUSTED_VERITY_ROOT_DIGESTS"
@@ -199,6 +200,7 @@ static int loadpin_load_data(enum kernel_load_data_id id, bool contents)
static struct lsm_id loadpin_lsmid __lsm_ro_after_init = {
.lsm = "loadpin",
+ .id = LSM_ID_LOADPIN,
};
static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
index 2004d67f7201..e8c41a0caf7d 100644
--- a/security/lockdown/lockdown.c
+++ b/security/lockdown/lockdown.c
@@ -13,6 +13,7 @@
#include <linux/security.h>
#include <linux/export.h>
#include <linux/lsm_hooks.h>
+#include <uapi/linux/lsm.h>
static enum lockdown_reason kernel_locked_down;
@@ -77,6 +78,7 @@ static struct security_hook_list lockdown_hooks[] __lsm_ro_after_init = {
static struct lsm_id lockdown_lsmid __lsm_ro_after_init = {
.lsm = "lockdown",
+ .id = LSM_ID_LOCKDOWN,
};
static int __init lockdown_lsm_init(void)
diff --git a/security/safesetid/lsm.c b/security/safesetid/lsm.c
index d9af1d04d293..8d0742ba045d 100644
--- a/security/safesetid/lsm.c
+++ b/security/safesetid/lsm.c
@@ -19,6 +19,7 @@
#include <linux/ptrace.h>
#include <linux/sched/task_stack.h>
#include <linux/security.h>
+#include <uapi/linux/lsm.h>
#include "lsm.h"
/* Flag indicating whether initialization completed */
@@ -263,6 +264,7 @@ static int safesetid_task_fix_setgroups(struct cred *new, const struct cred *old
static struct lsm_id safesetid_lsmid __lsm_ro_after_init = {
.lsm = "safesetid",
+ .id = LSM_ID_SAFESETID,
};
static struct security_hook_list safesetid_security_hooks[] = {
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index aee20bb1778d..5fcce36267bd 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -92,6 +92,7 @@
#include <linux/fsnotify.h>
#include <linux/fanotify.h>
#include <linux/io_uring.h>
+#include <uapi/linux/lsm.h>
#include "avc.h"
#include "objsec.h"
@@ -7016,6 +7017,7 @@ static int selinux_uring_cmd(struct io_uring_cmd *ioucmd)
static struct lsm_id selinux_lsmid __lsm_ro_after_init = {
.lsm = "selinux",
+ .id = LSM_ID_SELINUX,
};
/*
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 0c0fea933bbd..c7ba80e20b8d 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -43,6 +43,7 @@
#include <linux/fs_parser.h>
#include <linux/watch_queue.h>
#include <linux/io_uring.h>
+#include <uapi/linux/lsm.h>
#include "smack.h"
#define TRANS_TRUE "TRUE"
@@ -4789,6 +4790,7 @@ struct lsm_blob_sizes smack_blob_sizes __lsm_ro_after_init = {
static struct lsm_id smack_lsmid __lsm_ro_after_init = {
.lsm = "smack",
+ .id = LSM_ID_SMACK,
};
static struct security_hook_list smack_hooks[] __lsm_ro_after_init = {
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 80fbab5d2d7e..1916eb6216f7 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -6,6 +6,7 @@
*/
#include <linux/lsm_hooks.h>
+#include <uapi/linux/lsm.h>
#include "common.h"
/**
@@ -532,6 +533,7 @@ static void tomoyo_task_free(struct task_struct *task)
static struct lsm_id tomoyo_lsmid __lsm_ro_after_init = {
.lsm = "tomoyo",
+ .id = LSM_ID_TOMOYO,
};
/*
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index 4f60158850a7..2487b8f847f3 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -18,6 +18,7 @@
#include <linux/task_work.h>
#include <linux/sched.h>
#include <linux/spinlock.h>
+#include <uapi/linux/lsm.h>
#define YAMA_SCOPE_DISABLED 0
#define YAMA_SCOPE_RELATIONAL 1
@@ -423,6 +424,7 @@ static int yama_ptrace_traceme(struct task_struct *parent)
static struct lsm_id yama_lsmid __lsm_ro_after_init = {
.lsm = "yama",
+ .id = LSM_ID_YAMA,
};
static struct security_hook_list yama_hooks[] __lsm_ro_after_init = {
--
2.37.3
On Tue, Oct 25, 2022 at 11:45:13AM -0700, Casey Schaufler 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 <[email protected]>
> ---
> 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
>
> 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 */
Again, kerneldoc.
And if this crosses the user/kernel boundry, please make it __u64. Or
__s32? Something explicit please.
> };
>
> /*
> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
> new file mode 100644
> index 000000000000..d5bcbb9375df
> --- /dev/null
> +++ b/include/uapi/linux/lsm.h
> @@ -0,0 +1,32 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/*
> + * Linus Security Modules (LSM) - User space API
s/Linus/Linux/.
> + *
> + * Copyright (C) 2022 Casey Schaufler <[email protected]>
> + * Copyright (C) Intel Corporation
No date for Intel?
> + */
> +
> +#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.
> + *
> + * LSM_ID_XXX values 0 - 31 are reserved for future use
Reserved for what? Why?
thanks,
greg k-h
On 10/25/2022 10:58 PM, Greg KH wrote:
> On Tue, Oct 25, 2022 at 11:45:13AM -0700, Casey Schaufler 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 <[email protected]>
>> ---
>> 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
>>
>> 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 */
> Again, kerneldoc.
>
> And if this crosses the user/kernel boundry, please make it __u64. Or
> __s32? Something explicit please.
Will do.
>> };
>>
>> /*
>> diff --git a/include/uapi/linux/lsm.h b/include/uapi/linux/lsm.h
>> new file mode 100644
>> index 000000000000..d5bcbb9375df
>> --- /dev/null
>> +++ b/include/uapi/linux/lsm.h
>> @@ -0,0 +1,32 @@
>> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>> +/*
>> + * Linus Security Modules (LSM) - User space API
> s/Linus/Linux/.
Whoops.
>
>
>> + *
>> + * Copyright (C) 2022 Casey Schaufler <[email protected]>
>> + * Copyright (C) Intel Corporation
> No date for Intel?
The latest guidance I have received is that Intel does not want a date.
>> + */
>> +
>> +#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.
>> + *
>> + * LSM_ID_XXX values 0 - 31 are reserved for future use
> Reserved for what? Why?
You're not the first person to ask. I'll remove the reserved values
for the next version. The invalid value has to change as the id field
is going to be unsigned.
>
> thanks,
>
> greg k-h
>>> + */
>>> +
>>> +#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.
>>> + *
>>> + * LSM_ID_XXX values 0 - 31 are reserved for future use
>> Reserved for what? Why?
>
> You're not the first person to ask. I'll remove the reserved values
> for the next version. The invalid value has to change as the id field
> is going to be unsigned.
Don't define a user-visible static integer for LSM module.
We can continue using names or dynamically assigned integer.
https://lkml.kernel.org/r/[email protected]
Nacked-by: Tetsuo Handa <[email protected]>
On Wed, Oct 26, 2022 at 12:36:34PM -0700, Casey Schaufler wrote:
> >> + *
> >> + * Copyright (C) 2022 Casey Schaufler <[email protected]>
> >> + * Copyright (C) Intel Corporation
> > No date for Intel?
>
> The latest guidance I have received is that Intel does not want a date.
Ok, then I need to have an Intel lawyer sign off on a patch that does
this in order to have that be their official statement. Otherwise, it
needs a date.
> >> + */
> >> +
> >> +#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.
> >> + *
> >> + * LSM_ID_XXX values 0 - 31 are reserved for future use
> > Reserved for what? Why?
>
> You're not the first person to ask.
And the answer is?
> I'll remove the reserved values for the next version.
Because we asked it will be removed?
confused,
greg k-h
On 10/26/2022 11:31 PM, Greg KH wrote:
> On Wed, Oct 26, 2022 at 12:36:34PM -0700, Casey Schaufler wrote:
>>>> + *
>>>> + * Copyright (C) 2022 Casey Schaufler <[email protected]>
>>>> + * Copyright (C) Intel Corporation
>>> No date for Intel?
>> The latest guidance I have received is that Intel does not want a date.
> Ok, then I need to have an Intel lawyer sign off on a patch that does
> this in order to have that be their official statement. Otherwise, it
> needs a date.
Seems I misunderstood something. The date will be there.
>>>> + */
>>>> +
>>>> +#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.
>>>> + *
>>>> + * LSM_ID_XXX values 0 - 31 are reserved for future use
>>> Reserved for what? Why?
>> You're not the first person to ask.
> And the answer is?
There hasn't been an argument for it beyond "just in case".
I can't see a rational reason to reserve specific numbers as
I don't see value in LSM ranges.
>> I'll remove the reserved values for the next version.
> Because we asked it will be removed?
Because I don't have a good reason for including it and it
has been called into question. If a reviewer has a legitimate
case for reserved values they may be back.
> confused,
>
> greg k-h
On Tue, Oct 25, 2022 at 2:45 PM Casey Schaufler <[email protected]> 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 <[email protected]>
> ---
> 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.
> 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
On Fri, Oct 28, 2022 at 12:55 PM Casey Schaufler <[email protected]> wrote:
> On 10/26/2022 11:31 PM, Greg KH wrote:
> > On Wed, Oct 26, 2022 at 12:36:34PM -0700, Casey Schaufler wrote:
> >>>> + *
> >>>> + * Copyright (C) 2022 Casey Schaufler <[email protected]>
> >>>> + * Copyright (C) Intel Corporation
> >>> No date for Intel?
> >> The latest guidance I have received is that Intel does not want a date.
> > Ok, then I need to have an Intel lawyer sign off on a patch that does
> > this in order to have that be their official statement. Otherwise, it
> > needs a date.
>
> Seems I misunderstood something. The date will be there.
>
> >>>> + */
> >>>> +
> >>>> +#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.
> >>>> + *
> >>>> + * LSM_ID_XXX values 0 - 31 are reserved for future use
> >>> Reserved for what? Why?
> >> You're not the first person to ask.
> > And the answer is?
>
> There hasn't been an argument for it beyond "just in case".
> I can't see a rational reason to reserve specific numbers as
> I don't see value in LSM ranges.
>
> >> I'll remove the reserved values for the next version.
> > Because we asked it will be removed?
>
> Because I don't have a good reason for including it and it
> has been called into question. If a reviewer has a legitimate
> case for reserved values they may be back.
Sorry for the delay, I was away for a couple of weeks and limiting my
patch review to bug fixes, critical stuff, etc. but normal service is
resuming this week ...
I was the one who originally added the note on reserved values in my
original strawman proposal and I suspect Casey just carried that
forward into his patches, so feel free to blame me. My reason for
doing so is rather simple, we're going to treat the ID as a 32-bit
value so we have *plenty* of room (just the thought of supporting +4
billion unique LSMs is comically insane), and I'd like to try and
leave some space for yet-undetermined "special" things that we might
need to convey in the LSM syscalls. For example, this would allow us
to convey additional information to userspace when an application
asked for labeling information using one of these reserved LSM IDs;
applications which did not know (or care) about the special ID would
continue to function normally but augmented/new applications would be
able to make sense of the additional information ... and we wouldn't
have to add a new syscall to do it.
It's basically really cheap futureproofing with little downside (we
can always reclaim it at a later date if really necessary). I've done
similar things on other projects and it has proven to be useful in a
few, and in none of the cases has it proven to be a problem.
--
paul-moore.com
On 11/9/2022 3:33 PM, Paul Moore wrote:
> On Tue, Oct 25, 2022 at 2:45 PM Casey Schaufler <[email protected]> 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 <[email protected]>
>> ---
>> 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.
OK by me. One less compile+test cycle. It's nice to know there's some
limit on patch granularity.
>
>> 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 ...
Yes. The API friendly typing will be in the next revision.
> --
> paul-moore.com
On 11/9/2022 3:33 PM, Paul Moore wrote:
> On Fri, Oct 28, 2022 at 12:55 PM Casey Schaufler <[email protected]> wrote:
>> On 10/26/2022 11:31 PM, Greg KH wrote:
>>> On Wed, Oct 26, 2022 at 12:36:34PM -0700, Casey Schaufler wrote:
>>>>>> + *
>>>>>> + * Copyright (C) 2022 Casey Schaufler <[email protected]>
>>>>>> + * Copyright (C) Intel Corporation
>>>>> No date for Intel?
>>>> The latest guidance I have received is that Intel does not want a date.
>>> Ok, then I need to have an Intel lawyer sign off on a patch that does
>>> this in order to have that be their official statement. Otherwise, it
>>> needs a date.
>> Seems I misunderstood something. The date will be there.
>>
>>>>>> + */
>>>>>> +
>>>>>> +#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.
>>>>>> + *
>>>>>> + * LSM_ID_XXX values 0 - 31 are reserved for future use
>>>>> Reserved for what? Why?
>>>> You're not the first person to ask.
>>> And the answer is?
>> There hasn't been an argument for it beyond "just in case".
>> I can't see a rational reason to reserve specific numbers as
>> I don't see value in LSM ranges.
>>
>>>> I'll remove the reserved values for the next version.
>>> Because we asked it will be removed?
>> Because I don't have a good reason for including it and it
>> has been called into question. If a reviewer has a legitimate
>> case for reserved values they may be back.
> Sorry for the delay, I was away for a couple of weeks and limiting my
> patch review to bug fixes, critical stuff, etc. but normal service is
> resuming this week ...
>
> I was the one who originally added the note on reserved values in my
> original strawman proposal and I suspect Casey just carried that
> forward into his patches, so feel free to blame me.
Done!
> My reason for
> doing so is rather simple, we're going to treat the ID as a 32-bit
> value so we have *plenty* of room (just the thought of supporting +4
> billion unique LSMs is comically insane), and I'd like to try and
> leave some space for yet-undetermined "special" things that we might
> need to convey in the LSM syscalls. For example, this would allow us
> to convey additional information to userspace when an application
> asked for labeling information using one of these reserved LSM IDs;
> applications which did not know (or care) about the special ID would
> continue to function normally but augmented/new applications would be
> able to make sense of the additional information ... and we wouldn't
> have to add a new syscall to do it.
I don't see how
#define LSM_ID_SPECIAL 2
is better than
#define LSM_ID_SPECIAL 13
There's no reason to "group" LSM_ID values, nor have a range of them.
Really, I don't care one way or the other. I will bend to whatever will
is stronger.
> It's basically really cheap futureproofing with little downside (we
> can always reclaim it at a later date if really necessary). I've done
> similar things on other projects and it has proven to be useful in a
> few, and in none of the cases has it proven to be a problem.
>
> --
> paul-moore.com
On Wed, Nov 9, 2022 at 7:57 PM Casey Schaufler <[email protected]> wrote:
> On 11/9/2022 3:33 PM, Paul Moore wrote:
...
> > My reason for
> > doing so is rather simple, we're going to treat the ID as a 32-bit
> > value so we have *plenty* of room (just the thought of supporting +4
> > billion unique LSMs is comically insane), and I'd like to try and
> > leave some space for yet-undetermined "special" things that we might
> > need to convey in the LSM syscalls. For example, this would allow us
> > to convey additional information to userspace when an application
> > asked for labeling information using one of these reserved LSM IDs;
> > applications which did not know (or care) about the special ID would
> > continue to function normally but augmented/new applications would be
> > able to make sense of the additional information ... and we wouldn't
> > have to add a new syscall to do it.
>
> I don't see how
>
> #define LSM_ID_SPECIAL 2
>
> is better than
>
> #define LSM_ID_SPECIAL 13
>
> There's no reason to "group" LSM_ID values, nor have a range of them.
> Really, I don't care one way or the other. I will bend to whatever will
> is stronger.
The token values are not intended to be grouped in any sort of range,
it is just easier to say values 0-32 are reserved that create 33 macro
defines like LSM_ID_RESERVED1..LSM_ID_RESERVED32. The actual token
values shouldn't really mean anything, we could randomly assign them
if that helps get my point across, I just want a few reserved numbers
in the token space to leave room for future unknowns.
It's not like I'm suggesting something that has never been done before :)
--
paul-moore.com
On 11/23/2022 11:57 AM, Casey Schaufler wrote:
> Add two system calls for the Linux Security Module ABI.
Whoops. Sorry for the spam. Test posting escape. Please ignore.