[RFC,0/5] LSM: Officially support appending LSM hooks after boot.

Message

Tetsuo Handa Nov. 11, 2023, 10:07 a.m. UTC

This functionality will be used by TOMOYO security module.

In order to officially use an LSM module, that LSM module has to be
built into vmlinux. This limitation has been a big barrier for allowing
distribution kernel users to use LSM modules which the organization who
builds that distribution kernel cannot afford supporting [1]. Therefore,
I've been asking for ability to append LSM hooks from LKM-based LSMs so
that distribution kernel users can use LSMs which the organization who
builds that distribution kernel cannot afford supporting.

In order to unofficially use LSMs which are not built into vmlinux,
I've been maintaining AKARI as an LKM-based LSM which can run on kernels
between 2.6.0 and 6.6. But KP Singh's "Reduce overhead of LSMs with static
calls" proposal will make AKARI more difficult to run because it removes
the linked list. Therefore, reviving ability to officially append LSM
hooks from LKM-based LSMs became an urgent matter.

KP Singh suggested me to implement such LSMs as eBPF programs. But the
result is that eBPF is too restricted to emulate such LSMs [2]. Therefore,
I still need ability to append LSM hooks from LKM-based LSMs.

KP Singh commented

  I think what you can do is send patches for an API for LKM based LSMs
  and have it merged before my series, I will work with the code I have
  and make LKM based LSMs work. If this work gets merged, and your
  use-case is accepted (I think I can speak for at least Kees [if not
  others] too here) we will help you if you get stuck with MAX_LSM_COUNT
  or a dual static call and linked list based approach.

at [3] but I made this series on top of "[PATCH v7 0/5] Reduce overhead
of LSMs with static calls", for I wanted to know how to use static_calls()
and how does appending LSM hooks after boot will look like, with a hope
that LSM hooks that are appended after boot can also use static calls
so that the same structures/macros can be used for both built-in and
loadable LSM modules.

The result seems to be that linked list and static_call() are not
compatible, for a unique symbol name has to be assigned to each static
call. But I felt that we could avoid loop unrolling if we change the
direction from "call all individual callbacks from security/security.c"
to "call next callback at end of current callback if current callback
succeeded and next callback is defined, and security/security.c calls
only the first callback".

Link: https://lkml.kernel.org/r/[e-mail] [1]
Link: https://lkml.kernel.org/r/[e-mail] [2]
Link: https://lkml.kernel.org/r/CACYkzJ7ght66802wQFKzokfJKMKDOobYgeaCpu5Gx=[e-mail] [3]