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
--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit
