From: James Morris jmorris@namei.org
commit dd0859dccbe291cf8179a96390f5c0e45cb9af1d upstream.
Subsequent patches will add RO hardening to LSM hooks, however, SELinux still needs to be able to perform runtime disablement after init to handle architectures where init-time disablement via boot parameters is not feasible.
Introduce a new kernel configuration parameter CONFIG_SECURITY_WRITABLE_HOOKS, and a helper macro __lsm_ro_after_init, to handle this case.
Signed-off-by: James Morris james.l.morris@oracle.com Acked-by: Stephen Smalley sds@tycho.nsa.gov Acked-by: Casey Schaufler casey@schaufler-ca.com Acked-by: Kees Cook keescook@chromium.org Signed-off-by: Alexander Grund git@grundis.de --- include/linux/lsm_hooks.h | 7 +++++++ security/Kconfig | 5 +++++ security/selinux/Kconfig | 6 ++++++ 3 files changed, 18 insertions(+)
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index 53ac461f342b..65dfda2623c2 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h @@ -1921,6 +1921,13 @@ static inline void security_delete_hooks(struct security_hook_list *hooks, } #endif /* CONFIG_SECURITY_SELINUX_DISABLE */
+/* Currently required to handle SELinux runtime hook disable. */ +#ifdef CONFIG_SECURITY_WRITABLE_HOOKS +#define __lsm_ro_after_init +#else +#define __lsm_ro_after_init __ro_after_init +#endif /* CONFIG_SECURITY_WRITABLE_HOOKS */ + extern int __init security_module_enable(const char *module); extern void __init capability_add_hooks(void); #ifdef CONFIG_SECURITY_YAMA diff --git a/security/Kconfig b/security/Kconfig index 32f36b40e9f0..7d6edc5829a1 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -31,6 +31,11 @@ config SECURITY
If you are unsure how to answer this question, answer N.
+config SECURITY_WRITABLE_HOOKS + depends on SECURITY + bool + default n + config PAGE_TABLE_ISOLATION bool "Remove the kernel mapping in user mode" default y diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig index ea7e3efbe0f7..8af7a690eb40 100644 --- a/security/selinux/Kconfig +++ b/security/selinux/Kconfig @@ -40,6 +40,7 @@ config SECURITY_SELINUX_BOOTPARAM_VALUE config SECURITY_SELINUX_DISABLE bool "NSA SELinux runtime disable" depends on SECURITY_SELINUX + select SECURITY_WRITABLE_HOOKS default n help This option enables writing to a selinuxfs node 'disable', which @@ -50,6 +51,11 @@ config SECURITY_SELINUX_DISABLE portability across platforms where boot parameters are difficult to employ.
+ NOTE: selecting this option will disable the '__ro_after_init' + kernel hardening feature for security hooks. Please consider + using the selinux=0 boot parameter instead of enabling this + option. + If you are unsure how to answer this question, answer N.
config SECURITY_SELINUX_DEVELOP
From: James Morris jmorris@namei.org
commit ca97d939db114c8d1619e10a3b82af8615372dae upstream.
Mark all of the registration hooks as __ro_after_init (via the __lsm_ro_after_init macro).
Signed-off-by: James Morris james.l.morris@oracle.com Acked-by: Stephen Smalley sds@tycho.nsa.gov Acked-by: Kees Cook keescook@chromium.org Signed-off-by: Alexander Grund git@grundis.de --- security/apparmor/lsm.c | 2 +- security/commoncap.c | 2 +- security/security.c | 2 +- security/selinux/hooks.c | 2 +- security/smack/smack_lsm.c | 2 +- security/tomoyo/tomoyo.c | 2 +- security/yama/yama_lsm.c | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c index 02cc952b86aa..7b527c44857c 100644 --- a/security/apparmor/lsm.c +++ b/security/apparmor/lsm.c @@ -584,7 +584,7 @@ static int apparmor_task_setrlimit(struct task_struct *task, return error; }
-static struct security_hook_list apparmor_hooks[] = { +static struct security_hook_list apparmor_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(ptrace_access_check, apparmor_ptrace_access_check), LSM_HOOK_INIT(ptrace_traceme, apparmor_ptrace_traceme), LSM_HOOK_INIT(capget, apparmor_capget), diff --git a/security/commoncap.c b/security/commoncap.c index b86aca8d6798..0708c7f4df5f 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ -1071,7 +1071,7 @@ int cap_mmap_file(struct file *file, unsigned long reqprot,
#ifdef CONFIG_SECURITY
-struct security_hook_list capability_hooks[] = { +struct security_hook_list capability_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(capable, cap_capable), LSM_HOOK_INIT(settime, cap_settime), LSM_HOOK_INIT(ptrace_access_check, cap_ptrace_access_check), diff --git a/security/security.c b/security/security.c index 9a13d72a6446..b53c802c384b 100644 --- a/security/security.c +++ b/security/security.c @@ -1596,7 +1596,7 @@ int security_audit_rule_match(u32 secid, u32 field, u32 op, void *lsmrule, } #endif /* CONFIG_AUDIT */
-struct security_hook_heads security_hook_heads = { +struct security_hook_heads security_hook_heads __lsm_ro_after_init = { .binder_set_context_mgr = LIST_HEAD_INIT(security_hook_heads.binder_set_context_mgr), .binder_transaction = diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index b456c8630608..f60dfac48a99 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -6118,7 +6118,7 @@ static int selinux_key_getsecurity(struct key *key, char **_buffer)
#endif
-static struct security_hook_list selinux_hooks[] = { +static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(binder_set_context_mgr, selinux_binder_set_context_mgr), LSM_HOOK_INIT(binder_transaction, selinux_binder_transaction), LSM_HOOK_INIT(binder_transfer_binder, selinux_binder_transfer_binder), diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 84ed47195cdd..7926a374a567 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -4620,7 +4620,7 @@ static int smack_inode_getsecctx(struct inode *inode, void **ctx, u32 *ctxlen) return 0; }
-static struct security_hook_list smack_hooks[] = { +static struct security_hook_list smack_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(ptrace_access_check, smack_ptrace_access_check), LSM_HOOK_INIT(ptrace_traceme, smack_ptrace_traceme), LSM_HOOK_INIT(syslog, smack_syslog), diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c index 75c998700190..f1dce33d9542 100644 --- a/security/tomoyo/tomoyo.c +++ b/security/tomoyo/tomoyo.c @@ -496,7 +496,7 @@ static int tomoyo_socket_sendmsg(struct socket *sock, struct msghdr *msg, * tomoyo_security_ops is a "struct security_operations" which is used for * registering TOMOYO. */ -static struct security_hook_list tomoyo_hooks[] = { +static struct security_hook_list tomoyo_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(cred_alloc_blank, tomoyo_cred_alloc_blank), LSM_HOOK_INIT(cred_prepare, tomoyo_cred_prepare), LSM_HOOK_INIT(cred_transfer, tomoyo_cred_transfer), diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c index 5367f854fadc..be7e40c7e552 100644 --- a/security/yama/yama_lsm.c +++ b/security/yama/yama_lsm.c @@ -416,7 +416,7 @@ int yama_ptrace_traceme(struct task_struct *parent) return rc; }
-static struct security_hook_list yama_hooks[] = { +static struct security_hook_list yama_hooks[] __lsm_ro_after_init = { LSM_HOOK_INIT(ptrace_access_check, yama_ptrace_access_check), LSM_HOOK_INIT(ptrace_traceme, yama_ptrace_traceme), LSM_HOOK_INIT(task_prctl, yama_task_prctl),
On Sun, Jul 10, 2022 at 03:10:54PM +0200, theflamefire89@gmail.com wrote:
From: James Morris jmorris@namei.org
commit dd0859dccbe291cf8179a96390f5c0e45cb9af1d upstream.
Subsequent patches will add RO hardening to LSM hooks, however, SELinux still needs to be able to perform runtime disablement after init to handle architectures where init-time disablement via boot parameters is not feasible.
Introduce a new kernel configuration parameter CONFIG_SECURITY_WRITABLE_HOOKS, and a helper macro __lsm_ro_after_init, to handle this case.
Signed-off-by: James Morris james.l.morris@oracle.com Acked-by: Stephen Smalley sds@tycho.nsa.gov Acked-by: Casey Schaufler casey@schaufler-ca.com Acked-by: Kees Cook keescook@chromium.org Signed-off-by: Alexander Grund git@grundis.de
include/linux/lsm_hooks.h | 7 +++++++ security/Kconfig | 5 +++++ security/selinux/Kconfig | 6 ++++++ 3 files changed, 18 insertions(+)
What kernel version(s) are you wanting this applied to?
And your email send address does not match your signed-off-by name/address, so for obvious reasons, we can't take this.
thanks,
greg k-h
On Sun, Jul 10, 2022 at 03:26:45PM +0200, Greg KH wrote:
On Sun, Jul 10, 2022 at 03:10:54PM +0200, theflamefire89@gmail.com wrote:
From: James Morris jmorris@namei.org
commit dd0859dccbe291cf8179a96390f5c0e45cb9af1d upstream.
Subsequent patches will add RO hardening to LSM hooks, however, SELinux still needs to be able to perform runtime disablement after init to handle architectures where init-time disablement via boot parameters is not feasible.
Introduce a new kernel configuration parameter CONFIG_SECURITY_WRITABLE_HOOKS, and a helper macro __lsm_ro_after_init, to handle this case.
Signed-off-by: James Morris james.l.morris@oracle.com Acked-by: Stephen Smalley sds@tycho.nsa.gov Acked-by: Casey Schaufler casey@schaufler-ca.com Acked-by: Kees Cook keescook@chromium.org Signed-off-by: Alexander Grund git@grundis.de
include/linux/lsm_hooks.h | 7 +++++++ security/Kconfig | 5 +++++ security/selinux/Kconfig | 6 ++++++ 3 files changed, 18 insertions(+)
What kernel version(s) are you wanting this applied to?
And your email send address does not match your signed-off-by name/address, so for obvious reasons, we can't take this.
And of course, why is this needed in any stable kernel tree? It isn't fixing a bug, it's adding a new feature. Patch 2/2 also doesn't fix anything, so we need some explaination here. Perhaps do that in your 0/X email that I can't seem to find here?
thanks,
greg k-h
On 10.07.22 15:27, Greg KH wrote:
What kernel version(s) are you wanting this applied to?
That should go onto 4.9, I see I should have used `--subject-prefix`.
And your email send address does not match your signed-off-by name/address, so for obvious reasons, we can't take this.
My 2nd email (from GMail) is much easier to setup but I'd like to keep my usual signed-off tag. Would `--from=git@grundis.de --reply-to=theflamefire89@gmail.com` be acceptable?
And of course, why is this needed in any stable kernel tree? It isn't fixing a bug, it's adding a new feature. Patch 2/2 also doesn't fix anything, so we need some explaination here. Perhaps do that in your 0/X email that I can't seem to find here?
Good point, so I need to use `--cover-letter` even for backports. Makes sense. The previous discussion can be found at [1]. The essence is that this adds security hardening by disallowing writes to LSM hooks after initialization. Additionally included here to reduce divergence with mainline to ease application of further (backported) commits.
Regards, Alex
[1] https://patchwork.kernel.org/project/linux-hardening/patch/alpine.LRH.2.20.1...
On Sun, Jul 10, 2022 at 04:08:00PM +0200, Alexander Grund wrote:
On 10.07.22 15:27, Greg KH wrote:
What kernel version(s) are you wanting this applied to?
That should go onto 4.9, I see I should have used `--subject-prefix`.
And your email send address does not match your signed-off-by name/address, so for obvious reasons, we can't take this.
My 2nd email (from GMail) is much easier to setup but I'd like to keep my usual signed-off tag. Would `--from=git@grundis.de --reply-to=theflamefire89@gmail.com` be acceptable?
I can't see reply-to when reviewing a patch, can you?
What would you want to see if you had to review this to verify it was sane?
And of course, why is this needed in any stable kernel tree? It isn't fixing a bug, it's adding a new feature. Patch 2/2 also doesn't fix anything, so we need some explaination here. Perhaps do that in your 0/X email that I can't seem to find here?
Good point, so I need to use `--cover-letter` even for backports. Makes sense. The previous discussion can be found at [1]. The essence is that this adds security hardening by disallowing writes to LSM hooks after initialization. Additionally included here to reduce divergence with mainline to ease application of further (backported) commits.
We can't add new features to older kernel versions, as you know that's not allowed as per the stable kernel rules. If you want newer security features, just move to a newer kernel version.
And without any context here, or the "further" commits, how are we supposed to know any of this?
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Alexander Grund -
Greg KH -
theflamefire89＠gmail.com