LSM stacking in next for 6.1?

[Tetsuo Handa]

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