On Sat, Sep 23, 2023 at 07:15:05PM +0200, Mateusz Guzik wrote:
> On 9/23/23, Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
> > On 9/23/23, KP Singh <kpsingh@xxxxxxxxxx> wrote:
> >> On Fri, Sep 22, 2023 at 8:42 PM Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
> >>>
> >>> On Fri, Sep 22, 2023 at 04:55:00PM +0200, KP Singh wrote:
> >>> > Since we know the address of the enabled LSM callbacks at compile time
> >>> > and only
> >>> > the order is determined at boot time, the LSM framework can allocate
> >>> > static
> >>> > calls for each of the possible LSM callbacks and these calls can be
> >>> > updated once
> >>> > the order is determined at boot.
> >>> >
> >>>
> >>> Any plans to further depessimize the state by not calling into these
> >>> modules if not configured?
> >>>
> >>> For example Debian has a milipede:
> >>> CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf"
> >>>
> >>> Everything is enabled (but not configured).
> >>
> >> If it's not configured, we won't generate static call slots and even
> >> if they are in the CONFIG_LSM (or lsm=) they are simply ignored.
> >>
> >
> > Maybe there is a terminology mismatch here, so let me be more specific
> > with tomoyo as an example.
> >
> > In debian you have:
> > CONFIG_SECURITY_TOMOYO=y
> >
> > CONFIG_LSM, as per above, includes it on the list.
> >
> > At the same time debian does not ship any tooling to configure tomoyo
> > -- it is compiled into the kernel but not configured to enforce
> > anything.
> >
> > On stock kernel this results in tons of calls to
> > tomoyo_init_request_info, which are quite expensive due to an
> > avoidable memset thrown in, and which always return
> > tomoyo_init_request_info.
> >
>
> Erm, which always return TOMOYO_CONFIG_DISABLED.
>
> > Does not look like your patch whacks this problem.
> >
>
> So I am asking if there are plans to make these modules get out of the
> way if they have nothing to do, like tomoyo in the example above.
>
> Of course preferably distros would not make these weird configs, but I
> suspect this ship has sailed.
This is an artifact of the existing stacking behavior (and solving it,
if needed, can be done in parallel to this series). Specifically it
seems Tomoyo is in the "lsm=" list when it shouldn't be.
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...
-Kees
[1] https://lore.kernel.org/linux-security-module/202210171111.21E3983165@keescook/
--
Kees Cook
