TOMOYO's pull request for v6.12

[Casey Schaufler]

On 10/2/2024 1:12 PM, 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.

We wrangled with the BPF developers over a number of issues,
and in the end gave them something that's a lot more dangerous
than I'd like. With that in mind I can argue either of:

	Let's not do that again, revert.
	We need to trust our LSM developers in their own code, keep it.

What Tetsuo has implemented is a scheme that's been bouncing around for
some time. It is neither especially novel nor elegant. It is intended to
solve a particular issue, which is that Redhat distributions don't include
TOMOYO. [I should be corrected if that statement is not true] When we
talked about loadable modules in the past it was in the context of a
general mechanism, which I have always said I don't want to preclude.

I seriously doubt that this change would achieve the goal of getting
TOMOYO included in Redhat distributions. It seriously increases the
complexity of TOMOYO. It increases the attack surface on systems that
include TOMOYO. I don't see it as a win for TOMOYO.

As I look at the patch I see a proof of concept for a general mechanism.
If some of us were 30 years younger I would suggest that it be the basis
for research in that direction. I can see value in it, although it would
have to be complete and well reviewed. Perhaps someone with a decade to
spend on it can take what's been done and produce that implementation.

There has been a shift in the LSM community since Paul took over as
the maintainer. While he and I don't agree on much^H^H^H^H everything,
we are getting the sub-system under better control. For a long time
it was so hard to get anything into the LSM tree that Linus requested
the individual maintainers go to him directly. It's a lot easier now,
even without allowing for a significant backlog. It is a good thing
that changes within the LSMs are getting review. 

> 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.
>