Re: LSM stacking in next for 6.1?

On 2022/09/13 2:37, Casey Schaufler wrote: > That doesn't give us a good answer for loadable modules. The last time I looked > seriously at loadable modules I was considering that we'd need a security module > that manages them, very much like BPF manages the eBPF programs. Loadable modules > could use prctl, or some other mechanism, but they would have to be different > from built-in modules. You can't require built-in modules to conform to the > restrictions you'd have to impose on loadable ones. What I'm requesting (in other words, the biggest barrier I want to solve) is security/security.c | 1 + 1 file changed, 1 insertion(+) diff --git a/security/security.c b/security/security.c index 4b95de24bc8d..ed34e25af22b 100644 --- a/security/security.c +++ b/security/security.c @@ -73,6 +73,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = { }; struct security_hook_heads security_hook_heads __lsm_ro_after_init; +EXPORT_SYMBOL_GPL(security_hook_heads); static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain); static struct kmem_cache *lsm_file_cache; -- 2.18.4 and optionally (in other words, the second biggest barrier I want to solve is) security/security.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/security.c b/security/security.c index ed34e25af22b..4cc09e6cb32a 100644 --- a/security/security.c +++ b/security/security.c @@ -72,7 +72,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = { [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality", }; -struct security_hook_heads security_hook_heads __lsm_ro_after_init; +struct security_hook_heads security_hook_heads; EXPORT_SYMBOL_GPL(security_hook_heads); static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain);

-- 2.18.4 . A security module that manages loadable LSM modules cannot give us a good answer if there is a kernel config option to disable the manager security module.

As long as the death sentence remains, being able to disallow loadable LSMs is a very stupid decision. If a loadable kernel module were malicious, that module can do what AKARI/CaitSith are doing today using more disguised code. There should be a chance for ethical loadable LSM modules.

Kernels which seriously need security should be built with CONFIG_MODULES=n. Kernels which want to use loadable modules (not limited to LSM) but still need to remain secure should consider using e.g. CONFIG_MODULE_SIG=y. I consider that real bugs which may crash/compromise the kernel are reported by fuzz testing. Rather than disallowing loadable module LSMs, fixing real bugs should be the way to proceed.

> The Loadable Module Security > Module would have a static ID and somehow multiplex what lsm_self_attr() reports. I don't think loadable module LSM have a static ID. TOMOYO/AKARI/CaitSith are already working without "struct lsm_blob_sizes blob_sizes", without /proc/pid/attr/ interface, without modification of userspace programs. TOMOYO/AKARI/CaitSith are designed to avoid interface/resource conflicts you are trying to solve.

> I think it could be made to work. I can't say that it is something I am likely to > get to soon. The kernel config option and distribution's policy are preventing users from using non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work in distributor's kernels if above-mentioned changes are accepted.

https://bugzilla.redhat.com/show_bug.cgi?id=542986