TOMOYO's pull request for v6.12

[Paul Moore]

On Wed, Oct 2, 2024 at 10:43 PM Serge E. Hallyn <serge at hallyn.com> wrote:
> On Wed, Oct 02, 2024 at 04:12:50PM -0400, Paul Moore wrote:
> > Hi all,
> >
> > Hopefully by now you've at least seen the TOMOYO v6.12 pull request
> > thread; if you haven't read it yet, I suggest you do so before reading
> > the rest of this mail:
> >
> > https://lore.kernel.org/all/0c4b443a-9c72-4800-97e8-a3816b6a9ae2@I-love.SAKURA.ne.jp
> >
> > Of the three commits in the pull request, the commit which concerns me
> > the most is 8b985bbfabbe ("tomoyo: allow building as a loadable LSM
> > module").  The commit worries me as it brings management of the TOMOYO
> > LSM callbacks into TOMOYO itself, overriding the LSM framework.
> > Jonathan raises a similar point, although his issue is more focused on
> > the symbol export approach itself, rather than conceptual issues
> > relating to the LSM framework.  I will admit there are some high level
> > similarities to this approach and the BPF LSM, but I believe we can
> > say that the BPF LSM exception is necessary due to the nature of BPF,
> > and not something we want to see duplicated outside of that one
> > special case.
> >
> > As I wrote in my original response to this pull request, this is not
> > something I would accept in a new LSM submission and thus I feel
> > compelled to speak out against this change and submit a revert to
> > Linus.  However, as the LSM framework exists to satisfy the needs of
> > the individual LSMs, I've tried to ensure that significant changes
> > like these are done with support of the majority of LSMs.  I
> > understand that in a case like this, reverting LSM-specific commits,
> > individual LSM maintainers may not want to speak up on the issue so
> > I'm going to let this message sit on-list until Friday morning, unless
> > I see the majority of the LSMs voicing support *against* reverting the
> > TOMOYO commit above (and the other related commit) I will proceed with
> > submitting the revert to Linus on Friday.  I would prefer if all
> > responses are sent on-list, but you can also mail me privately with
> > your objection to the revert and I will include it in the count.
> >
> > Thanks.
>
> Huh!  Honestly, when I read the thread, especially Jon's comments, I was
> worried.  But getting a chance to look at the patch now, it actually
> seems good to me.  No one is getting affected unless they enable
> CONFIG_TOMOYO_LKM.  Even those distros which have been enabling TOMOYO
> won't be exporting new hooks without a config change, iiuc.

I don't want to set a precedent of individual LSMs managing how they
plug into the rest of the kernel; at best it results in a lot of code
duplication between the individual LSM and the framework, at worst it
opens the door for buggy interactions and difficult to predict
behavior.  Look at all the work we've done over the past couple of
years to cleanup how the LSM framework manages the individual LSM
callbacks both to reduce the chances of error and improve performance.
Sidestepping this by allowing individual LSMs to implement their own
layer of callback management is a big step backwards and not something
I want to see supported.

-- 
paul-moore.com