LSM stacking in next for 6.1?

[Tetsuo Handa]

On 2022/10/26 7:41, Casey Schaufler wrote:
>             You need a built-in LSM that loads and manages loadable
> security modules.

That is no longer loadable LSM modules. A loadable LSM module must be capable of
loading any code and using any interface that is allowed to loadable kernel modules
using /sbin/insmod command. That is my understanding of what you have promised (and
the reason I am allowing you to continue working on LSM stacking before I make
CONFIG_SECURITY_TOMOYO=m).

>                   That LSM would have an LSM ID just like the BPF LSM
> has a LSM ID.

There can't be a LSM that manages loadable security modules. TOMOYO can't be loaded
via such LSM, for TOMOYO needs to e.g. create /sys/kernel/security/tomoyo/ interface.
A contained program like BPF can't get such flexibility, and a LSM that manages
loadable security modules can't manage flexible/unconfined programs.

>                   That LSM would have an LSM ID just like the BPF LSM
> has a LSM ID.

Whatever LSM modules that are in-tree will have an LSM id. But you must remember
that not all LSM modules are in-tree (and won't be able to get in-tree).
The LSM id I'm talking about is for LSM modules that cannot get in-tree.

>               I have no doubt that there are multiple workable implementations,
> as I have looked into many different ways to implement the stacking for
> built-in modules.

Please enumerate some that can satisfy our promise.

Even if there is a LSM that manages loadable LSMs, loadable LSMs can't get LSM id
because what loadable LSMs will do is beyond what the BPF LSM can do.
Loadable LSMs by nature needs to be able to have unique identifier (currently
module name, and you are trying to change from name to integer which some of
loadable LSMs cannot get).

>                   I am also sorry that I don't expect to have enough working
> years left to even consider spending any more time on the problem. This is
> a development effort for The Next Generation.

If you segregate built-in LSM modules and loadable LSM modules (remember,
not all LSM modules will be able to get in-tree and built-in), userspace won't be
able to use LSM id you are trying to introduce. Your LSM id makes LSM framework
worse than now.

You are killing The Next Generation due to "only in-tree and supported by
distributors is correct" crap.