TOMOYO's pull request for v6.12

John Johansen john.johansen at canonical.com
Thu Oct 3 03:05:48 UTC 2024


On 10/2/24 19:43, Serge E. Hallyn 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.
> 
for now, but when that doesn't get enabled when does it silently
change from under us?

This is the wrong approach and it is going to force us to disable
Tomoyo if it isn't reverted.





More information about the Linux-security-module-archive mailing list