[PATCH] LSM: allow loadable kernel module based LSM modules

[Paul Moore]

On Sat, Sep 7, 2024 at 6:14 AM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
> On 2024/09/06 23:24, Paul Moore wrote:
> > On Fri, Sep 6, 2024 at 3:43 AM Tetsuo Handa
> > <penguin-kernel at i-love.sakura.ne.jp> wrote:
> >> If you ignore my concern, I have to NACK the static call changes you are
> >> going to send in the upcoming merge window.
> >
> > I'm not ignoring your concern, I've responded to your emails and
> > patches on the topic over, and over, and over, and over again by
> > trying to explain to you that your goal of supporting out-of-tree LSMs
> > regardless of the impact to the upstream LSM effort is not something
> > that is acceptable to the upstream LSM effort, or the Linux kernel in
> > general.
>
> I want LKM-based LSM support in order to allow one of in-tree LSMs (namely
> TOMOYO) to be delivered to my intended users ...

As discussed many times already, the solution to in-tree LSMs not
being enabled is to simply enable them in a kernel for your users.  If
your users are limited to a specific kernel configuration due to
distro support issues/contracts, that is a problem you need to address
with the relevant distribution.  If the distribution is unwilling to
alter their kernel configuration to suit your needs, or your users,
that still does not make this an upstream problem, it is a problem
between you, your users, and the distribution.

> Adding Nacked-by: lines is not an indulgence for ignoring my concerns.

Adding NACKs, just like adding ACKs or any other patch metadata, is my
responsibility, nothing more, nothing less.

> Commit f3b8788cde61 ("LSM: Identify modules by more than name") is an example
> you added Nacked-by: line without adding hints for why I nacked it (e.g.
> links to my posts).

Please see the associated pull request email I sent to Linus where I
wrote several sentences about your objections:

https://lore.kernel.org/linux-security-module/3f5a7bc467d221543444a268dd1a1fe0@paul-moore.com

"Support amongst the individual LSM developers has been nearly
unanimous, with a single objection coming from Tetsuo (TOMOYO) as he
is worried that the LSM_ID_XXX token concept will make it more
difficult for out-of-tree LSMs to survive.  Several members of the LSM
 community have demonstrated the ability for out-of-tree LSMs to
continue to exist by picking high/unused LSM_ID values as well as
pointing out that many kernel APIs rely on integer identifiers, e.g.
syscalls (!), but unfortunately Tetsuo's objections remain.  My
personal opinion is that while I have no interest in penalizing
out-of-tree LSMs, I'm not going to penalize in-tree development to
support out-of-tree development, and I view this as a necessary step
forward to support the push for expanded LSM stacking and reduce our
reliance on /proc and /sys which has occassionally been problematic
for some container users."

Unless you present any new ideas in this thread, which I consider
highly unlikely at this point, this will be my last email to you in
this thread.  As mentioned previously, if you would like to see your
NACK recorded in the static call patch, let me know.

-- 
paul-moore.com