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