LSM stacking in next for 6.1?

[Casey Schaufler]

On 9/13/2022 3:47 AM, Tetsuo Handa wrote:
> 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);

I don't see either of these changes happening. I'm not the right person
to argue either side, but I understand the rationale for keeping them
private. That's why I think we need to have a different mechanism for
loadable modules, and why it needs to be optional.

>  
> -- 
> 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.

The community that is absolutely opposed to loadable modules will disagree.

> 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.

My understanding of the argument is that while an in-tree, built in module
will be subject to appropriate review, you can't say that about an out-of-tree,
loadable module.

> 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.

A significant portion (maybe the majority) of security work being done
today is based on the notion that we can't fix all the bugs or exclude all
the malicious code, so we better protect specific bits of code from the
rest. Fuzz testing is a wonderful tool, but won't find everything.

> >                                                     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.

A loadable module would have to be managed differently from a built-in one.
Hence the notion of a loadable module manager.

> > 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.

You should be able to use TOMOYO as a built-in along side other security modules
today. Aside from getting the distribution to include it in their kernel
configuration, which is admittedly no mean feat, and getting any user-space you
need included, you should already have what you need.

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

Ten years ago they said "Don't want to, aren't going to". Sadly, I doubt
there would be a different attitude today. The decision to support a security
module in a distribution is serious. I can definitely see how Redhat would
have their hands full supporting SELinux.