[PATCH v4 0/5] Reduce overhead of LSMs with static calls

[Mateusz Guzik]

On 9/24/23, Kees Cook <keescook at chromium.org> wrote:
> That said, I've long advocated[1] for a way to explicitly disable LSMs
> without affecting operational ordering. I think it would be very nice to
> be able to boot with something like:
>
> lsm=!yama
>
> to disable Yama. Or for your case, "lsm=!tomoyo". Right now, you have to
> figure out what the lsm list is, and then create a new one with the
> LSM you want disabled removed from the list. i.e. with v6.2 and later
> check the boot log, and you'll see:
>
> LSM: initializing lsm=lockdown,capability,landlock,yama,integrity,apparmor
>
> If you wanted to boot with Yama removed, you'd then pass:
>
> 	lsm=lockdown,capability,landlock,integrity,apparmor
>
> As a boot param. But I think this is fragile since now any new LSMs will
> be by-default disabled once a sysadmin overrides the "lsm" list. Note
> that booting with "lsm.debug=1" will show even more details. See commit
> 86ef3c735ec8 ("LSM: Better reporting of actual LSMs at boot").
>
> So, if a distro has no support for an LSM but they want it _available_
> in the kernel, they should leave it built in, but remove it from the
> "lsm=" list. That's a reasonable bug to file against a distro...
>

Maybe I once more expressed myself poorly, I meant to say stock Debian
does not ship any tooling for tomoyo, but the kernel has support
compiled in.

Ultimately, after stacking got implemented, it was inevitable diestros
like Debian will enable whatever modules and expect them to not be a
problem if not configured by userspace.

I don't think any form of messing with CONFIG_LSM is a viable option,
even if you make it a boot param.

What should happen instead is that modules which are not given any
config don't get in the way.

-- 
Mateusz Guzik <mjguzik gmail.com>