TOMOYO's pull request for v6.12
Casey Schaufler
casey at schaufler-ca.com
Thu Oct 3 16:58:37 UTC 2024
On 10/3/2024 9:42 AM, Serge E. Hallyn wrote:
> On Thu, Oct 03, 2024 at 09:36:00AM -0700, Casey Schaufler wrote:
>> 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.
> Just checking - do you mean revert this, but not BPF LSM? :)
That is correct. Not that I wouldn't relish the notion of reverting
both, mind you.
>> 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
> Right, I think this is the biggest reason to request the revert, unless
> Redhat or fedora tells us that they would actually enable it.
Just so.
More information about the Linux-security-module-archive
mailing list