TOMOYO's pull request for v6.12

TOMOYO's pull request for v6.12

[Paul Moore]

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.

-- 
paul-moore.com

Re: TOMOYO's pull request for v6.12

[Serge E. Hallyn]

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.

-serge

Re: TOMOYO's pull request for v6.12

[Serge E. Hallyn]

On Wed, Oct 02, 2024 at 09:43:07PM -0500, 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.
> 
> -serge

OTOH I am worried about the threatening sentence:

> This backdoor symbol-export mechanism is a transitional hack needed for
> demonstrating that loadable LSM can work. This hack will be replaced with
> proper symbol-export via appropriate trees after this merge window closes.


(in 7dce903c-2f76-43b2-bb6f-808cb50d0696@I-love.SAKURA.ne.jp)

-serge

Re: TOMOYO's pull request for v6.12

[John Johansen]

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.

Re: TOMOYO's pull request for v6.12

[Paul Moore]

On Wed, Oct 2, 2024 at 10:43 PM Serge E. Hallyn <serge@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

Re: TOMOYO's pull request for v6.12

[Serge E. Hallyn]

On Thu, Oct 03, 2024 at 11:32:39AM -0400, Paul Moore wrote:
> On Wed, Oct 2, 2024 at 10:43 PM Serge E. Hallyn <serge@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.

That's reasonable.  And I agree with John that, because of the way this
was "snuck in", if I were a distro building a tomoyo-enabled kernel, I
would now have trust issues.  But I don't think anyone else will come
to Tetsuo's defense, so I just wanted to point out that, while the
process was very much done wrongly, I think code-wise he's done the most
responsible thing he could - given his end goals.  Even so,

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

Well, this didn't occur to me last night, but what I'd be curious to
hear is whether Tetsuo has discussed this with RedHat.  Because unless
this makes them say "ok we'll enable that", it still doesn't help him.
And I don't imagine them agreeing to enable the CONFIG_TOMOYO_LKM.

-serge

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

Re: TOMOYO's pull request for v6.12

[Serge E. Hallyn]

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?  :)

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

Re: TOMOYO's pull request for v6.12

[Paul Moore]

On Thu, Oct 3, 2024 at 12:42 PM Serge E. Hallyn <serge@hallyn.com> wrote:
>
> Right, I think this is the biggest reason to request the revert, unless
> Redhat or fedora tells us that they would actually enable it.

To be clear, my objection is independent of what RedHat thinks about
this approach, although we have heard from at least one person with a
distro "hat" that this approach is counter productive and would result
in TOMOYO being disabled if not reverted.  This is simply the wrong
approach to take upstream.

If RedHat wants to enable TOMOYO they have that ability now, but as
we've heard countless times they are not interested in doing so.

-- 
paul-moore.com

Re: TOMOYO's pull request for v6.12

[Casey Schaufler]

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. 

Re: TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/04 1:29, Serge E. Hallyn wrote:
> Well, this didn't occur to me last night, but what I'd be curious to
> hear is whether Tetsuo has discussed this with RedHat.  Because unless
> this makes them say "ok we'll enable that", it still doesn't help him.
> And I don't imagine them agreeing to enable the CONFIG_TOMOYO_LKM.

Majority of Linux users I work for are using Red Hat. But I have absolutely
too little relationship with Red Hat people to involve somebody else into
this problem. Too little attention/interest to make progress.
https://bugzilla.redhat.com/show_bug.cgi?id=2303689

Chicken-and-egg problem here; since TOMOYO is not available in Red Hat
kernels, I have no room/chance to help/involve with Red Hat community.

If I implement a subset of TOMOYO that does not refuse requests (something
like SELinux without the "enforcing mode"), can such LSM module be accepted
by the upstream kernel? (The "patent examination" is a barrier for doing it.)

You might think that such LSM module is not a security. But TOMOYO is
also used as a sort of system-wide strace-like profiler. Understanding
what the users' systems are doing is useful/helpful for users.

If one of Red Hat's worries that refusing requests due to broken policy is
gone, the barrier for enabling such LSM module in Red Hat's kernels will be
lowered. If such LSM module becomes available in Red Hat kernels, I might be
able to find room/chance to help/involve with Red Hat community.

Re: TOMOYO's pull request for v6.12

[Mickaël Salaün]

On Fri, Oct 04, 2024 at 07:50:05PM +0900, Tetsuo Handa wrote:
> On 2024/10/04 1:29, Serge E. Hallyn wrote:
> > Well, this didn't occur to me last night, but what I'd be curious to
> > hear is whether Tetsuo has discussed this with RedHat.  Because unless
> > this makes them say "ok we'll enable that", it still doesn't help him.
> > And I don't imagine them agreeing to enable the CONFIG_TOMOYO_LKM.
> 
> Majority of Linux users I work for are using Red Hat. But I have absolutely

My understanding is that Red Hat's customers must ask for a feature for
it to be available (in a future version), so you should ask your users
to support the request.

I wish Landlock would be available everywhere too, but this requires
some effort.  Even when an LSM is built-in, it may not be enabled by
default and then not available to most users because of the "lsm="
cmdline or CONFIG_LSM...  To protect as much users as possible
(potentially without their knowledge), we have the burden of convincing
distros and other parts of the Linux ecosystems that a security feature
is worth it.

> too little relationship with Red Hat people to involve somebody else into
> this problem. Too little attention/interest to make progress.
> https://bugzilla.redhat.com/show_bug.cgi?id=2303689
> 
> Chicken-and-egg problem here; since TOMOYO is not available in Red Hat
> kernels, I have no room/chance to help/involve with Red Hat community.
> 
> If I implement a subset of TOMOYO that does not refuse requests (something
> like SELinux without the "enforcing mode"), can such LSM module be accepted
> by the upstream kernel? (The "patent examination" is a barrier for doing it.)
> 
> You might think that such LSM module is not a security. But TOMOYO is
> also used as a sort of system-wide strace-like profiler. Understanding
> what the users' systems are doing is useful/helpful for users.

I think an LSM is not the right tool for tracing because it only sees a
subset of the access requests: other security mechanisms may deny
requests before they reach an LSM.  Linux provides great tracing
mechanisms though.

> 
> If one of Red Hat's worries that refusing requests due to broken policy is
> gone, the barrier for enabling such LSM module in Red Hat's kernels will be
> lowered. If such LSM module becomes available in Red Hat kernels, I might be
> able to find room/chance to help/involve with Red Hat community.

The question is about potential maintenance cost vs. ROI, not only
security policy issues.  I guess Red Hat would not care about bugs in
non-default service configurations, eBPF programs, nor LSM policies, but
they will if additional code potentially impacts other parts of the
system and may increase the number of potential bugs, and then the
maintenance cost.  Open source is not free for everyone.

Re: TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/04 22:11, Mickaël Salaün wrote:
> On Fri, Oct 04, 2024 at 07:50:05PM +0900, Tetsuo Handa wrote:
>> On 2024/10/04 1:29, Serge E. Hallyn wrote:
>>> Well, this didn't occur to me last night, but what I'd be curious to
>>> hear is whether Tetsuo has discussed this with RedHat.  Because unless
>>> this makes them say "ok we'll enable that", it still doesn't help him.
>>> And I don't imagine them agreeing to enable the CONFIG_TOMOYO_LKM.
>>
>> Majority of Linux users I work for are using Red Hat. But I have absolutely
> 
> My understanding is that Red Hat's customers must ask for a feature for
> it to be available (in a future version), so you should ask your users
> to support the request.

I myself is not a RHEL user. I use RockyLinux and Ubuntu for improving quality
of the upstream kernels via fixing bugs syzbot finds. (Unfortunately, currently
the "static call" change is preventing me from spending my resource for this
activity, for "static call" broke AKARI.)

My customers are RHEL users, and I'm working for their RHEL systems, with my
feeling that how their projects becomes easy if I can profile their systems
using TOMOYO. But my customers do not know about TOMOYO. I have no channel to
introduce TOMOYO to relevant persons who are in a position of giving
permissions for contacting Red Hat support using their RHEL subscriptions.

>> You might think that such LSM module is not a security. But TOMOYO is
>> also used as a sort of system-wide strace-like profiler. Understanding
>> what the users' systems are doing is useful/helpful for users.
> 
> I think an LSM is not the right tool for tracing because it only sees a
> subset of the access requests: other security mechanisms may deny
> requests before they reach an LSM.  Linux provides great tracing
> mechanisms though.

LSM is the best-fitting tool for my purpose.
You can see an example at https://youtu.be/5cgqbQI9bEM .



>> If one of Red Hat's worries that refusing requests due to broken policy is
>> gone, the barrier for enabling such LSM module in Red Hat's kernels will be
>> lowered. If such LSM module becomes available in Red Hat kernels, I might be
>> able to find room/chance to help/involve with Red Hat community.
> 
> The question is about potential maintenance cost vs. ROI, not only
> security policy issues.  I guess Red Hat would not care about bugs in
> non-default service configurations, eBPF programs, nor LSM policies, but
> they will if additional code potentially impacts other parts of the
> system and may increase the number of potential bugs, and then the
> maintenance cost.  Open source is not free for everyone.

Without ability to do conversations, potential maintenance cost vs. ROI
cannot be evaluated. And I can't gain chances/ability to do conversations
with relevant people...

Re: TOMOYO's pull request for v6.12

[Kees Cook]

On Wed, Oct 02, 2024 at 04:12:50PM -0400, Paul Moore wrote:
> 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.

The patch should be reverted regardless of the LSM specifics:

- The patch is (extremely) non-trivial and:

  - was never posted to any mailing list, which means there was no
    opportunity for discussion

  - did not appear in linux-next, which means there was no opportunity
    for any integration or similar testing

- The patch provides new symbol exports without any discussion nor buy-in
  from the symbol owners. (I do appreciate that it was written to be
  extremely narrowly scoped, but it doesn't matter: it's new exports.)

Given the social history of the code in question, I think the patch
should be reverted due to its _intent_. The above items do not look like
accidents nor oversights, but rather an explicit attempt to bypass the
normal consensus-based development practices of Linux itself.

It's also a red flag that the code was written 6 days before the merge
window -- even if there HAD been discussion, that is an extremely narrow
time frame to propose it for a pull request.

Speaking to the implementation, it's a clever use of static calls, but:

- it internalizes features that were designed to be commonly implemented
  and NOT used internally by an LSM.

- tomoyo_register_hooks() becomes an exploitation gadget that could be
  used to bypass the LSM as a whole.

The first issue is more of a code pattern and best practices issue. The
latter is the core problem I personally have with the implementation:
LSMs are one of the first targets during memory corruption attacks,
so we've tried to reduce their attack surface very aggressively. That
generally translates into making any function pointers (or associated
tables, manipulation routines, etc) read-only.

That this patch would result in TOMOYO getting enabled on RedHat seems
extraordinarily unlikely as RH went out of its way to remove from upstream
the very last part of SELinux that might provide this kind of read-only
bypass: CONFIG_SECURITY_WRITABLE_HOOKS. See f22f9aaf6c3d ("selinux:
remove the runtime disable functionality").

So, no, I think this endangers the other LSMs, has not been discussed
with any other parties, and has likely no path forward in RedHat.

It may be possible to change RH's mind about enabling TOMOYO, though, as
it was denied[1] almost 13 years ago and MUCH has changed since then. A
good place to start would be a new bug report, which has happened[2],
but has yet to be triaged and was only opened 2 months ago. I would
recommend reaching out to the RH kernel team directly...

-Kees

[1] https://bugzilla.redhat.com/show_bug.cgi?id=542986#c8
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2303689

-- 
Kees Cook

Re: TOMOYO's pull request for v6.12

[Paul Moore]

On Fri, Oct 4, 2024 at 4:54 PM Kees Cook <kees@kernel.org> wrote:
>
> On Wed, Oct 02, 2024 at 04:12:50PM -0400, Paul Moore wrote:
> > 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.
>
> The patch should be reverted regardless of the LSM specifics ...

Just in case people haven't seen this already:

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

-- 
paul-moore.com

Re: TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/05 5:54, Kees Cook wrote:
> - tomoyo_register_hooks() becomes an exploitation gadget that could be
>   used to bypass the LSM as a whole.

tomoyo_register_hooks() is enabled only if "CONFIG_SECURITY_TOMOYO_LKM is
included while building the kernel" && "security=tomoyo is specified or
tomoyo is included in the lsm= kernel command line options".

Therefore, those who are building kernels with CONFIG_SECURITY_TOMOYO_LKM=n are
not affected.

Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, callbacks
registered by tomoyo_register_hooks() won't be called unless "security=tomoyo
is specified or tomoyo is included in the lsm= kernel command line options", for
the proxy callbacks that use static call tables are not registered.

Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, and "security=tomoyo
is specified or tomoyo is included in the lsm= kernel command line options",
tomoyo_register_hooks() can be called only once. And tomoyo.ko is loaded by the
time /sbin/init (nowadays /usr/lib/systemd/systemd) starts. That is, by the time
an attacker can login from console or can start attacking via network,
tomoyo_register_hooks() is no longer callable.

If an attacker can control boot behavior before /sbin/init (nowadays
/usr/lib/systemd/systemd) starts (e.g. by editing kernel boot command line, or
loading malicious kernel module from initramfs before tomoyo.ko is loaded), that
system was already compromised and is a different problem. (If kernel command line
options were modified to enable only capability (i.e. "lsm=capability"), how can
selinux/apparmor etc. can protect that system?)

Therefore, the only problem with tomoyo.ko approach is that the static call tables
for tomoyo_register_hooks() are currently not marked as __ro_after_init. But it will
be possible to make the static call tables read-only if the static call tables
are aligned in a page boundary and an architecture-dependent kernel API that changes
given page's attribute to read-only is called. (This is why __ro_after_init can work,
isn't it?)

As a whole, I don't think tomoyo.ko approach is unacceptably dangerous.

Re: TOMOYO's pull request for v6.12

[Kees Cook]

On Sat, Oct 05, 2024 at 08:41:06AM +0900, Tetsuo Handa wrote:
> On 2024/10/05 5:54, Kees Cook wrote:
> > - tomoyo_register_hooks() becomes an exploitation gadget that could be
> >   used to bypass the LSM as a whole.
> 
> tomoyo_register_hooks() is enabled only if "CONFIG_SECURITY_TOMOYO_LKM is
> included while building the kernel" && "security=tomoyo is specified or
> tomoyo is included in the lsm= kernel command line options".
> 
> Therefore, those who are building kernels with CONFIG_SECURITY_TOMOYO_LKM=n are
> not affected.

Sure, but my point is that convincing RedHat that this is acceptable is
likely to be an uphill battle considering their effort to gain full
ro_after_init coverage for SELinux.

> Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, callbacks
> registered by tomoyo_register_hooks() won't be called unless "security=tomoyo
> is specified or tomoyo is included in the lsm= kernel command line options", for
> the proxy callbacks that use static call tables are not registered.

This part I overlooked. I forgot that Tomoyo is still not fully stackable,
so it isn't getting included in CONFIG_LSM= for the distros that do
build it.

> Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, and "security=tomoyo
> is specified or tomoyo is included in the lsm= kernel command line options",
> tomoyo_register_hooks() can be called only once.

An attacker with a read/write primitive would be able to locate and
write to "registered" (since it is not read-only), allowing them to call
tomoyo_register_hooks() multiple times.

> And tomoyo.ko is loaded by the
> time /sbin/init (nowadays /usr/lib/systemd/systemd) starts. That is, by the time
> an attacker can login from console or can start attacking via network,
> tomoyo_register_hooks() is no longer callable.

See above -- calling tomoyo_register_hooks() after boot is entirely
feasible given a read/write attack primitive.

> Therefore, the only problem with tomoyo.ko approach is that the static call tables
> for tomoyo_register_hooks() are currently not marked as __ro_after_init. But it will
> be possible to make the static call tables read-only if the static call tables

The tables actually don't matter as much -- an attacker could construct
their own table anywhere in kernel memory and pass that as an argument
for their call to tomoyo_register_hooks().

(This is actually one of the reasons I have pushed to have sensitive
functions like that be able to check that their passed-in argument is
contained in a read-only area, but that didn't get much traction[1].)

> are aligned in a page boundary and an architecture-dependent kernel API that changes
> given page's attribute to read-only is called. (This is why __ro_after_init can work,
> isn't it?)

The __ro_after_init section is immediately neighboring the .rodata
section, so when .rodata is marked read-only (after __init has
finished), the kernel marks both sections read-only. (Except for, I
think, s390, which does two passes: .rodata is read-only before __init,
and then __ro_after_init is marked read-only after __init.)

> As a whole, I don't think tomoyo.ko approach is unacceptably dangerous.

I agree, this implementation is safer than I initial assessed (due to the
LSM's view of the hooks being skipped due to lsm= not including tomoyo).
I still think how this patch ended up in Linus's tree was a big mistake,
though.

Regardless, my opinion is unchanged: I think it will be harder to convince
RedHat to build in _this_ version of tomoyo compared to the stock version.

(Out of curiosity, does RedHat build in AppArmor?)

-Kees

[1] https://lore.kernel.org/lkml/202408052100.74A2316C27@keescook/

-- 
Kees Cook

Re: TOMOYO's pull request for v6.12

[John Johansen]

On 10/4/24 17:17, Kees Cook wrote:
> On Sat, Oct 05, 2024 at 08:41:06AM +0900, Tetsuo Handa wrote:
>> On 2024/10/05 5:54, Kees Cook wrote:
>>> - tomoyo_register_hooks() becomes an exploitation gadget that could be
>>>    used to bypass the LSM as a whole.
>>
>> tomoyo_register_hooks() is enabled only if "CONFIG_SECURITY_TOMOYO_LKM is
>> included while building the kernel" && "security=tomoyo is specified or
>> tomoyo is included in the lsm= kernel command line options".
>>
>> Therefore, those who are building kernels with CONFIG_SECURITY_TOMOYO_LKM=n are
>> not affected.
> 
> Sure, but my point is that convincing RedHat that this is acceptable is
> likely to be an uphill battle considering their effort to gain full
> ro_after_init coverage for SELinux.
> 

I concur. From a disto pov modules can be worse than builtin. The size difference
here really isn't worth the hassle of building tomoyo as a module.

>> Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, callbacks
>> registered by tomoyo_register_hooks() won't be called unless "security=tomoyo
>> is specified or tomoyo is included in the lsm= kernel command line options", for
>> the proxy callbacks that use static call tables are not registered.
> 
> This part I overlooked. I forgot that Tomoyo is still not fully stackable,
> so it isn't getting included in CONFIG_LSM= for the distros that do
> build it.
> 
>> Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, and "security=tomoyo
>> is specified or tomoyo is included in the lsm= kernel command line options",
>> tomoyo_register_hooks() can be called only once.
> 
> An attacker with a read/write primitive would be able to locate and
> write to "registered" (since it is not read-only), allowing them to call
> tomoyo_register_hooks() multiple times.
> 
>> And tomoyo.ko is loaded by the
>> time /sbin/init (nowadays /usr/lib/systemd/systemd) starts. That is, by the time
>> an attacker can login from console or can start attacking via network,
>> tomoyo_register_hooks() is no longer callable.
> 
> See above -- calling tomoyo_register_hooks() after boot is entirely
> feasible given a read/write attack primitive.
> 
>> Therefore, the only problem with tomoyo.ko approach is that the static call tables
>> for tomoyo_register_hooks() are currently not marked as __ro_after_init. But it will
>> be possible to make the static call tables read-only if the static call tables
> 
> The tables actually don't matter as much -- an attacker could construct
> their own table anywhere in kernel memory and pass that as an argument
> for their call to tomoyo_register_hooks().
> 
> (This is actually one of the reasons I have pushed to have sensitive
> functions like that be able to check that their passed-in argument is
> contained in a read-only area, but that didn't get much traction[1].)
> 
yep, its a real shame

>> are aligned in a page boundary and an architecture-dependent kernel API that changes
>> given page's attribute to read-only is called. (This is why __ro_after_init can work,
>> isn't it?)
> 
> The __ro_after_init section is immediately neighboring the .rodata
> section, so when .rodata is marked read-only (after __init has
> finished), the kernel marks both sections read-only. (Except for, I
> think, s390, which does two passes: .rodata is read-only before __init,
> and then __ro_after_init is marked read-only after __init.)
> 
>> As a whole, I don't think tomoyo.ko approach is unacceptably dangerous.
> 
> I agree, this implementation is safer than I initial assessed (due to the
> LSM's view of the hooks being skipped due to lsm= not including tomoyo).
> I still think how this patch ended up in Linus's tree was a big mistake,
> though.
> 
> Regardless, my opinion is unchanged: I think it will be harder to convince
> RedHat to build in _this_ version of tomoyo compared to the stock version.
> 
> (Out of curiosity, does RedHat build in AppArmor?)
> 

No they don't

Re: TOMOYO's pull request for v6.12

[John Johansen]

On 10/3/24 09:29, Serge E. Hallyn wrote:
> On Thu, Oct 03, 2024 at 11:32:39AM -0400, Paul Moore wrote:
>> On Wed, Oct 2, 2024 at 10:43 PM Serge E. Hallyn <serge@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.
> 
> That's reasonable.  And I agree with John that, because of the way this
> was "snuck in", if I were a distro building a tomoyo-enabled kernel, I
> would now have trust issues.  But I don't think anyone else will come
> to Tetsuo's defense, so I just wanted to point out that, while the
> process was very much done wrongly, I think code-wise he's done the most
> responsible thing he could - given his end goals.  Even so,
> 
its an interesting approach. Its something I am willing to discuss further
as an extension module of the LSM, not in an individual LSM.

>> 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.
> 
> Well, this didn't occur to me last night, but what I'd be curious to
> hear is whether Tetsuo has discussed this with RedHat.  Because unless
> this makes them say "ok we'll enable that", it still doesn't help him.
> And I don't imagine them agreeing to enable the CONFIG_TOMOYO_LKM.
> 
> -serge

Re: TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/05 9:17, Kees Cook wrote:
>> Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, callbacks
>> registered by tomoyo_register_hooks() won't be called unless "security=tomoyo
>> is specified or tomoyo is included in the lsm= kernel command line options", for
>> the proxy callbacks that use static call tables are not registered.
> 
> This part I overlooked. I forgot that Tomoyo is still not fully stackable,
> so it isn't getting included in CONFIG_LSM= for the distros that do
> build it.

Excuse me, but TOMOYO is fully stackable since Linux 5.1.
The reason tomoyo isn't getting included in CONFIG_LSM= is that majority of
CONFIG_SECURITY_TOMOYO=y distro kernel users do not need TOMOYO. (Also,
needlessly enabling TOMOYO when userspace tools for TOMOYO is not installed
causes a needless kernel message.)

> 
>> Even if kernels are built with CONFIG_SECURITY_TOMOYO_LKM=y, and "security=tomoyo
>> is specified or tomoyo is included in the lsm= kernel command line options",
>> tomoyo_register_hooks() can be called only once.
> 
> An attacker with a read/write primitive would be able to locate and
> write to "registered" (since it is not read-only), allowing them to call
> tomoyo_register_hooks() multiple times.

But we can mitigate it by making "static calls" in tomoyo_register_hooks() read-only
before returning from tomoyo_register_hooks(). Changes we need will be

  locate the "static calls" tables in tomoyo_register_hooks() into a page aligned
  address (like __ro_after_init section), and call the API that updates page attributes
  containing the tables read-only
  ( https://sourceforge.net/p/tomoyo/akari/HEAD/tree/tags/patches/1.0.50/lsm-4.12.c#l1347 )

. I think that we can define what l1347 does as an API for the LSM framework if the LSM
framework needs it in order to allow hook registration after __init phase completed.

> 
>> And tomoyo.ko is loaded by the
>> time /sbin/init (nowadays /usr/lib/systemd/systemd) starts. That is, by the time
>> an attacker can login from console or can start attacking via network,
>> tomoyo_register_hooks() is no longer callable.
> 
> See above -- calling tomoyo_register_hooks() after boot is entirely
> feasible given a read/write attack primitive.

See above. By making the "static calls" tables read-only before returning from
tomoyo_register_hooks(), calling tomoyo_register_hooks() again after somehow
resetting "registered" variable in tomoyo_register_hooks() will just fail with
crashing the kernel.

Please don't say what if an attacker with a read/write primitive is able to locate
variables and do what l1338 does. That is a never-ending story. The read-only in
the kernel space is implemented as a page attribute. If the attacker can do what
l1338 does, neither "const" nor "__ro_after_init" can make variables read-only.

>> As a whole, I don't think tomoyo.ko approach is unacceptably dangerous.
> 
> I agree, this implementation is safer than I initial assessed (due to the
> LSM's view of the hooks being skipped due to lsm= not including tomoyo).
> I still think how this patch ended up in Linus's tree was a big mistake,
> though.

Commit 8b985bbfabbe ("tomoyo: allow building as a loadable LSM module") says

  This patch is intended for demonstrating that there is nothing difficult
  for supporting TOMOYO-like loadable LSM modules.

. https://lkml.kernel.org/r/7dce903c-2f76-43b2-bb6f-808cb50d0696@I-love.SAKURA.ne.jp says

  Since Paul Moore continues ignoring my concerns, waiting for support of loadable
  LSMs at LSM framework layer won't help. I had to express my concerns and
  demonstrate/prove that loadable LSM can work immediately. I know that people shall
  forget my concerns if I didn't take action right now.

. I really wanted to hear all of your concerns when I responded that "static call"
makes loadable LSM modules difficult. We had whole one year of time before I had to
go with this pull request.

I think that this pull request succeeded in revealing what LSM community thinks.
Each developer is thinking different things. One thinks "anyone can rebuild kernels
with whatever changes", but that opinion ignored secure boot / module signing part.
"You need to discard existing security in order to use an LSM module which is not
built-in" is not something a security person should say. In practice, only known
entities like distributors can build kernels and sign them. This results in attempt
to built-in whatever LSM modules into the distributor kernels. And many of you are
saying that the distributor builds kernels with TOMOYO built-in is better than
separating as tomoyo.ko . And the same thing will be applicable to other LSMs such
as Landlock. Since distributors have upstream-first policy (does not want to build
kernel code that are not included into the upstream kernel), the pressure to make
whatever LSM modules included in the upstream kernel will get stronger. The bandwidth
problem will remain, but at least I think that the "patent examination" needs to be
removed. I believe that the only requirement for getting an LSM module accepted in
the upstream kernel is that the author/supporter of an LSM module remains cooperative
about solving problems (fixing bugs). It is possible that an attempt to make it
possible to use SELinux and Smack together is a wrong direction. Even if SELinux
and TSEM conflicts about their security models (and cannot be used together), it
might not be something we need to care...

Re: TOMOYO's pull request for v6.12

[Casey Schaufler]

On 10/5/2024 12:10 AM, Tetsuo Handa wrote:
> ... It is possible that an attempt to make it
> possible to use SELinux and Smack together is a wrong direction. Even if SELinux
> and TSEM conflicts about their security models (and cannot be used together), it
> might not be something we need to care...

In the past I have said that having SELinux and Smack on the same system
is the test case for module stacking, but that I didn't see it having a
practical application. I have since been presented with a use case that
seems reasonable. Because LSM is a mechanism for additional restrictions
it is impossible for two security models to "conflict". LSMs *must* be
written to allow for cases where access is denied for other reasons. You
never get to the MAC check if the DAC check has already failed. If TSEM
can't handle what SELinux or TOMOYO decides it shouldn't be accepted.

Of course, there are details of the Linux kernel (e.g. secmarks) that
prove the rule. These are not issues of "model", but of implementation.

Re: TOMOYO's pull request for v6.12

[Paul Moore]

On Sat, Oct 5, 2024 at 3:11 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> I think that this pull request succeeded in revealing what LSM community thinks.
> Each developer is thinking different things. One thinks "anyone can rebuild kernels
> with whatever changes", but that opinion ignored secure boot / module signing part.

As I believe that I'm the developer quoted above, let me say that my
comment did not ignore UEFI SB.  The Machine Owner Key (MOK) concept
provided by shims/bootloaders is designed just for this use case.
More advanced users can even replace the UEFI SB key databases, on
hardware that supports it, with their own to permit loading of their
self-built kernels without the need for the MOK; this is arguably one
of the most "secure" UEFI SB configurations.

I've successfully used MOK on my own systems to support my own kernel
builds, and I've successfully replaced the UEFI SB key databases in
VMs to use UEFI SB and my own kernel builds without MOK.

-- 
paul-moore.com

Re: TOMOYO's pull request for v6.12

[Dr. Greg]

On Sat, Oct 05, 2024 at 09:10:08AM -0700, Casey Schaufler wrote:

Good morning to everyone, I hope the weekend is going well.

I saw this go by while I was multi-tasking between draining the oil
out of the lower unit on my boat motor and welding the boat lift
canopy frame and wanted to make sure that Tetsuo's comment is
interpreted in the correct context.

> On 10/5/2024 12:10 AM, Tetsuo Handa wrote:
> > ... It is possible that an attempt to make it
> > possible to use SELinux and Smack together is a wrong direction. Even if SELinux
> > and TSEM conflicts about their security models (and cannot be used together), it
> > might not be something we need to care...

> In the past I have said that having SELinux and Smack on the same
> system is the test case for module stacking, but that I didn't see
> it having a practical application. I have since been presented with
> a use case that seems reasonable. Because LSM is a mechanism for
> additional restrictions it is impossible for two security models to
> "conflict". LSMs *must* be written to allow for cases where access
> is denied for other reasons. You never get to the MAC check if the
> DAC check has already failed. If TSEM can't handle what SELinux or
> TOMOYO decides it shouldn't be accepted.

I believe that Tetsuo misinterpreted the discussions you and I have
had about what represents a 'security model'.

For the record, TSEM has no issue with handling whatever SeLinux,
SMACK, Tomoyo, AppArmor et.al. decide to do, full stop.

It functions like all of the rest of the LSM modules, it determines
whether or not a security event is inconsistent with the 'model' that
the process is running in, and if so denies it, otherwise it stands
aside and lets the other LSM's have a run at it.

If some other LSM in front of it decides to deny an event, well and
good, the event is over with from TSEM's perspective, as well as
anything else behind the denying LSM for that matter.

You raised the issue, I believe in V1, as to where we had positioned
TSEM in the LSM call list.  After you expressed concern we moved it to
the front of the call list because we don't care and everyone else
seems to want to be later in the stack, particularly at the end, which
would now seem to be be a privileged position held only by BPF.

To extend on this a bit for further clarification.

As we have evolved TSEM we realized that we actually want to be first,
if that isn't also a coveted position.

For example, internally, we have TSEM 'models' whose only function is
to validate that the extended security attributes of an inode match
what the workload was unit tested to, in order to thwart offline
modification attacks.  In this case you want TSEM to be running ahead
of the security attribute based models, since presumably, you would
not want those models making a decision on extended attributes that
have been modified.

Hopefully this clarifies the issue.

We have a long standing question, that has never been answered,
regarding module stacking and multiple MAC implementations on the same
OS instance but we will leave that to another conversation.

Now back to MIG welder.

Have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

Re: TOMOYO's pull request for v6.12

[Simon Thoby]

On 10/5/24 6:30 PM, Paul Moore wrote:
> On Sat, Oct 5, 2024 at 3:11 AM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>> I think that this pull request succeeded in revealing what LSM community thinks.
>> Each developer is thinking different things. One thinks "anyone can rebuild kernels
>> with whatever changes", but that opinion ignored secure boot / module signing part.
> 
> As I believe that I'm the developer quoted above, let me say that my
> comment did not ignore UEFI SB.  The Machine Owner Key (MOK) concept
> provided by shims/bootloaders is designed just for this use case.
> More advanced users can even replace the UEFI SB key databases, on
> hardware that supports it, with their own to permit loading of their
> self-built kernels without the need for the MOK; this is arguably one
> of the most "secure" UEFI SB configurations.
> 
> I've successfully used MOK on my own systems to support my own kernel
> builds, and I've successfully replaced the UEFI SB key databases in
> VMs to use UEFI SB and my own kernel builds without MOK.
> 

Indeed, I'm probably sidetracking the discussion a bit, but I have met all three use
cases both personally and professionally:
- Signing an out-of-tree kernel modules with a local certificate (MOK) enrolled in the
  MOKList via shim (e.g. to support Nvidia GPUs on SecureBoot-enabled machines)
- Enrolling user boot keys (changing the PK, adding my own KEK to Microsoft's and the platform
  manufacturer's, then extending the DB list) the signing my kernel with my own key
- Completely replacing the secure boot keys to only allow my own (sadly, this may be risky
  on some platforms, like ThinkPads, where essential UEFIs drivers may not load, thus
  bricking the device)

I say all this to emphasize that the options outlined by Paul are not theoretical, but
very practical use cases that one may encounter in the industry (and I have, even
in fairly conservative industries).
In addition, I strongly believe this is the way to go: any kernel module or dynamic
configuration (if I push this idea to the extreme, maybe in the future this could
even include eBPF payloads in some hardened configurations) should be signed by a trusted
authority to be loaded in the kernel.
That authority may be the Linux distribution, but it can also be you (or your company
IT department), thanks to MOK (or its heavier alternatives).
You retain the flexibility to load kernel modules not built by the distributor,
or even out-of-tree modules, but without degrading the security of your computers
(assuming the signing keys are properly protected, of course).

Perhaps you would be better served by providing your users with a snippet of documentation
explaining how to configure MOK and to rebuild the RHEL kernel with TOMOYO enabled?
To be fair, I know that your customers may find this a time-consuming ordeal compared to using
the official kernel - especially as you want to keep up with the frequent updates.
But OTOH that's not end-of-the-world complexity either, which makes it fine for occasional use,
e.g. to behave like "a sort of system-wide strace-like profiler" (I'm guessing your customers
are only doing this operation from time to time, not continuously in production).
There's no perfect solution I guess, but to keep lobbying distributors to enabled TOMOYO
in their kernels.

Simon

Re: TOMOYO's pull request for v6.12

[Casey Schaufler]

On 10/5/2024 10:02 AM, Dr. Greg wrote:
> On Sat, Oct 05, 2024 at 09:10:08AM -0700, Casey Schaufler wrote:
>
> Good morning to everyone, I hope the weekend is going well.
>
> I saw this go by while I was multi-tasking between draining the oil
> out of the lower unit on my boat motor and welding the boat lift
> canopy frame and wanted to make sure that Tetsuo's comment is
> interpreted in the correct context.

Playing with welders and petrochemicals at the same time is
not recommended. Boom! Ack!

>> On 10/5/2024 12:10 AM, Tetsuo Handa wrote:
>>> ... It is possible that an attempt to make it
>>> possible to use SELinux and Smack together is a wrong direction. Even if SELinux
>>> and TSEM conflicts about their security models (and cannot be used together), it
>>> might not be something we need to care...
>> In the past I have said that having SELinux and Smack on the same
>> system is the test case for module stacking, but that I didn't see
>> it having a practical application. I have since been presented with
>> a use case that seems reasonable. Because LSM is a mechanism for
>> additional restrictions it is impossible for two security models to
>> "conflict". LSMs *must* be written to allow for cases where access
>> is denied for other reasons. You never get to the MAC check if the
>> DAC check has already failed. If TSEM can't handle what SELinux or
>> TOMOYO decides it shouldn't be accepted.
> I believe that Tetsuo misinterpreted the discussions you and I have
> had about what represents a 'security model'.
>
> For the record, TSEM has no issue with handling whatever SeLinux,
> SMACK, Tomoyo, AppArmor et.al. decide to do, full stop.
>
> It functions like all of the rest of the LSM modules, it determines
> whether or not a security event is inconsistent with the 'model' that
> the process is running in, and if so denies it, otherwise it stands
> aside and lets the other LSM's have a run at it.
>
> If some other LSM in front of it decides to deny an event, well and
> good, the event is over with from TSEM's perspective, as well as
> anything else behind the denying LSM for that matter.
>
> You raised the issue, I believe in V1, as to where we had positioned
> TSEM in the LSM call list.  After you expressed concern we moved it to
> the front of the call list because we don't care and everyone else
> seems to want to be later in the stack, particularly at the end, which
> would now seem to be be a privileged position held only by BPF.
>
> To extend on this a bit for further clarification.
>
> As we have evolved TSEM we realized that we actually want to be first,
> if that isn't also a coveted position.

The current thought is that we frown on an LSM desiring a specific
ordering and would probably reject one that required it.

> For example, internally, we have TSEM 'models' whose only function is
> to validate that the extended security attributes of an inode match
> what the workload was unit tested to, in order to thwart offline
> modification attacks.  In this case you want TSEM to be running ahead
> of the security attribute based models, since presumably, you would
> not want those models making a decision on extended attributes that
> have been modified.
>
> Hopefully this clarifies the issue.
>
> We have a long standing question, that has never been answered,
> regarding module stacking and multiple MAC implementations on the same
> OS instance but we will leave that to another conversation.

I would be open to hearing which of the many open questions you're
referring to. 

>
> Now back to MIG welder.
>
> Have a good weekend.
>
> As always,
> Dr. Greg
>
> The Quixote Project - Flailing at the Travails of Cybersecurity
>               https://github.com/Quixote-Project
>

Re: TOMOYO's pull request for v6.12

[Paul Moore]

On Sat, Oct 5, 2024 at 2:58 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 10/5/2024 10:02 AM, Dr. Greg wrote:

...

> > As we have evolved TSEM we realized that we actually want to be first,
> > if that isn't also a coveted position.
>
> The current thought is that we frown on an LSM desiring a specific
> ordering and would probably reject one that required it.

Agreed.  We do have a couple LSMs that do require some specific
ordering rules, but those are typically for safety related reasons
realized after the fact, or some legacy/compat reason.  I'm not going
to say we would 100% reject an LSM that required a specific ordering,
but there would be a *lot* of questions about that requirement during
review :)

> > For example, internally, we have TSEM 'models' whose only function is
> > to validate that the extended security attributes of an inode match
> > what the workload was unit tested to, in order to thwart offline
> > modification attacks.  In this case you want TSEM to be running ahead
> > of the security attribute based models, since presumably, you would
> > not want those models making a decision on extended attributes that
> > have been modified.

In this particular case it shouldn't matter from an access control
perspective.  Sure, you might end up doing some extra work in a LSM if
TSEM were to occur later in the ordering and ends up rejecting the
operation, but that really is no different from any other case where a
LSM later in the ordering rejects an operation that was allowed by all
the others before it.  The important thing to remember is that just
because a given LSM authorizes an operation, it does not mean the
operation will successfully run to completion.  Even in the single LSM
case, with the LSM access control happening so early in the code path,
there are often multiple ways an operation can fail, e.g. -ENOMEM.

-- 
paul-moore.com

Re: TOMOYO's pull request for v6.12

[Serge E. Hallyn]

On Sat, Oct 05, 2024 at 07:28:35PM +0200, Simon Thoby wrote:
...
> Perhaps you would be better served by providing your users with a snippet of documentation
> explaining how to configure MOK and to rebuild the RHEL kernel with TOMOYO enabled?
> To be fair, I know that your customers may find this a time-consuming ordeal compared to using
> the official kernel - especially as you want to keep up with the frequent updates.

Tetsuo's problem, AIUI, is not that it's difficult to rebuild the kernel enabling
tomoyo, it's that once his customers do so, RedHat will not support/debug in case
of failures.

> But OTOH that's not end-of-the-world complexity either, which makes it fine for occasional use,
> e.g. to behave like "a sort of system-wide strace-like profiler" (I'm guessing your customers
> are only doing this operation from time to time, not continuously in production).
> There's no perfect solution I guess, but to keep lobbying distributors to enabled TOMOYO
> in their kernels.
> 
> Simon

Re: TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/06 9:02, Serge E. Hallyn wrote:
> On Sat, Oct 05, 2024 at 07:28:35PM +0200, Simon Thoby wrote:
> ...
>> Perhaps you would be better served by providing your users with a snippet of documentation
>> explaining how to configure MOK and to rebuild the RHEL kernel with TOMOYO enabled?
>> To be fair, I know that your customers may find this a time-consuming ordeal compared to using
>> the official kernel - especially as you want to keep up with the frequent updates.
> 
> Tetsuo's problem, AIUI, is not that it's difficult to rebuild the kernel enabling
> tomoyo, it's that once his customers do so, RedHat will not support/debug in case
> of failures.

There are a lot of problems.

TOMOYO is a personal project (the company when I wrote TOMOYO is no longer
involved since 2012). Also, the company I currently belong to does not have
much involvement in OSS community. There are some Java programmers, but there
are little C programmers. Programmers who can understand the Linux kernel are
endangered species. And I'm working as a troubleshooting staff who can investigate
problems using C programmer's skill / Linux kernel developer's knowledge.

Because such a situation, talking with managers needs to be done at a level for
non-programmers, and communicating with developers/operators needs to be done
using almost copy-and-paste level procedure manual. In short, Linux systems are
black-box for them, and I want to use TOMOYO as one of tools for helping them to
escape from black-box.

Most of Linux systems are RHEL servers, but since TOMOYO is not included in RHEL
kernels, I can't use TOMOYO. I was using AKARI until now, but the "static calls"
change broke AKARI. Thus, I'm close to panic() condition.

As far as I'm involved in, all RHEL servers are running inside protected
environment (e.g. commercial WAF/IPS devices inspect traffics before forwarding,
commercial firewalls/LBs devices minimize possible networking communication
routes, SSO is enforced for users to login, AV/EDR are protecting individual
server). Because such a situation, there is little needs for updating packages
due to security bugs. It may not be a good practice, but even packages that
reached EOL might be used for years after EOL. For such environments, e.g.
TSC counter overflows after 208.5 days and freezes the system is more impacting
problem and is the reason to update kernel packages.

I could rebuild RHEL kernels with TOMOYO enabled. But I can't afford providing
infrastructure for distributing rebuilt kernels / packages relevant with the
rebuilt kernels (e.g. debuginfo packages) nor resource for acting as front-end
for receiving any problems that happens with the rebuilt kernels. How difficult
will it be to let my customers rebuild RHEL kernels with TOMOYO enabled and
let my customers prove Red Hat that the cause of their problem (bugs) is in
stock RHEL kernels? (Not limited to runtime bugs, but also questions etc. for
configuring kernel part that is not related to TOMOYO.) As with problems that
happen when using e.g. out-of-tree products, I need to rely on Linux distributor
as front-end. As a back-end, I will handle problems (bugs) in TOMOYO part.

It is AV / EDR companies who are most thinking empathetically and contributing
to security for my customer's individual RHEL servers. What the LSM community
considers as threats and what my customers consider as threats are different.
It is sad that the LSM community does not like e.g. loadable LSM modules despite
writable variables are not a practical attack vector for my customers...



Going back to tomoyo.ko seen from my customers point of view.

Advantage of building TOMOYO into vmlinux is that the procedure for
communicating with managers/developers/operators becomes simple.

Advantage of building TOMOYO as tomoyo.ko is that users can update only
tomoyo.ko (thanks to KABI in RHEL kernels) when a bug is found in TOMOYO.
Minimizing possible code changes helps minimizing cost for updating packages.
But secure boot / module signing (not a topic to consider for current
environment, but possibly becomes a topic to consider for future environment)
needs to be taken into account.

I'm not familiar with secure boot / module signing. I had a feeling that effectively
only distributors can sign tomoyo.ko . But it seems that I can also sign tomoyo.ko
if conditions are met. But I won't be able to provide infrastructure / support for
problems related to secure boot, for I need to prepare copy-and-paste level
procedure manual (not a snippet!) and support. tomoyo.ko being signed by
distributors is much appreciated.

Re: TOMOYO's pull request for v6.12

[Simon Thoby]

On 10/6/24 12:02 PM, Tetsuo Handa wrote:
> On 2024/10/06 9:02, Serge E. Hallyn wrote:
>> On Sat, Oct 05, 2024 at 07:28:35PM +0200, Simon Thoby wrote:
>> ...
>>> Perhaps you would be better served by providing your users with a snippet of documentation
>>> explaining how to configure MOK and to rebuild the RHEL kernel with TOMOYO enabled?
>>> To be fair, I know that your customers may find this a time-consuming ordeal compared to using
>>> the official kernel - especially as you want to keep up with the frequent updates.
>>
>> Tetsuo's problem, AIUI, is not that it's difficult to rebuild the kernel enabling
>> tomoyo, it's that once his customers do so, RedHat will not support/debug in case
>> of failures.

You're probably right. In my email I said it could be "fine for occasional use" where users
want to trace the system when a problem occurs.
Of course this only works if the problem is reproducible (or frequent enough) that you can
build a new kernel with TOMOYO enabled, boot on it, and wait for the problem to produce itself.
If the goal is instead to have TOMOYO enabled at all time on the company systems, then I
do not envy Tetsuo's position, because I believe this to be an impasse (regarding TOMOYO
itself, not necessarily the tracing problem - more on that later).

> 
> There are a lot of problems.
> 
> TOMOYO is a personal project (the company when I wrote TOMOYO is no longer
> involved since 2012). Also, the company I currently belong to does not have
> much involvement in OSS community. There are some Java programmers, but there
> are little C programmers. Programmers who can understand the Linux kernel are
> endangered species. And I'm working as a troubleshooting staff who can investigate
> problems using C programmer's skill / Linux kernel developer's knowledge.
> 
> Because such a situation, talking with managers needs to be done at a level for
> non-programmers, and communicating with developers/operators needs to be done
> using almost copy-and-paste level procedure manual. In short, Linux systems are
> black-box for them, and I want to use TOMOYO as one of tools for helping them to
> escape from black-box.
> 
> Most of Linux systems are RHEL servers, but since TOMOYO is not included in RHEL
> kernels, I can't use TOMOYO. I was using AKARI until now, but the "static calls"
> change broke AKARI. Thus, I'm close to panic() condition.
> 
> As far as I'm involved in, all RHEL servers are running inside protected
> environment (e.g. commercial WAF/IPS devices inspect traffics before forwarding,
> commercial firewalls/LBs devices minimize possible networking communication
> routes, SSO is enforced for users to login, AV/EDR are protecting individual
> server). Because such a situation, there is little needs for updating packages
> due to security bugs. It may not be a good practice, but even packages that
> reached EOL might be used for years after EOL. For such environments, e.g.
> TSC counter overflows after 208.5 days and freezes the system is more impacting
> problem and is the reason to update kernel packages.

I personally does not agree with the position that "there is little needs for updating
packages due to security bugs", because I believe this does not account for one important
source of attacks: the internal actor, working inside the company, and thus behind all
your WAF/IPS/Firewalls and whatnot (I do not say this to belittle these tools, they help
protect your company against external actors, but they do not protect against a malicious
or angry employee). So updates (not just security updates, after all in the kernel it is
very hard to know what update carries a security fix) are always a good thing in my book.

But fair enough, I have also seen the "If it ain’t broke, don’t fix it" quite a fair
amount of time in a few years working with the industry. And when you cannot justify
investing money into upgrades with your hierarchy, you have to compromise.

Anyway, I sidetracked myself again :/

> 
> I could rebuild RHEL kernels with TOMOYO enabled. But I can't afford providing
> infrastructure for distributing rebuilt kernels / packages relevant with the
> rebuilt kernels (e.g. debuginfo packages) nor resource for acting as front-end
> for receiving any problems that happens with the rebuilt kernels. How difficult
> will it be to let my customers rebuild RHEL kernels with TOMOYO enabled and
> let my customers prove Red Hat that the cause of their problem (bugs) is in
> stock RHEL kernels? (Not limited to runtime bugs, but also questions etc. for
> configuring kernel part that is not related to TOMOYO.) As with problems that
> happen when using e.g. out-of-tree products, I need to rely on Linux distributor
> as front-end. As a back-end, I will handle problems (bugs) in TOMOYO part.
> 
> It is AV / EDR companies who are most thinking empathetically and contributing
> to security for my customer's individual RHEL servers. What the LSM community
> considers as threats and what my customers consider as threats are different.
> It is sad that the LSM community does not like e.g. loadable LSM modules despite
> writable variables are not a practical attack vector for my customers...
>

The difficulty is that the LSM community need to think of what's best for all users,
and that include users where the writable static calls may be an exploitable path.
If RedHat were to enable TOMOYO_LKM, they would expose their users to that risk.
Thus, I do not believe (as maybe have said already) that your patch would serve
your objective of getting it added into RedHat, but rather the contrary: guaranteeing
that RedHat will never enable it in Fedora/RHEL kernels.

While I sympathize with your position (between the anvil of not getting TOMOYO enabled
in distributions and the hammer of your customers in need of solutions), I do not
think this design of a LKM updating static calls that provide security functions
holds a real chance of getting merged someday.


On another note, the way the patch was sent to Linus (very close to the end of the
merge window, and without CC'ing the linux-security-module ML) may be seen as a way
to bypass reviewers and get it merged "no matter what". While I do not attribute
malice to that merge request, I understand that it may be somewhat ill perceived.
Which again, may warp RedHat's (and others, like Canonical's) perception of TOMOYO
negatively.
Maintaining a piece of kernel functionality for over a decade in an impressive feat,
and I commend you for that, but I know that losing trust is often far easier (and takes
far less effort) than regaining it afterwards.
And I think the "trust credit" may play an important role in the political aspects
of enabling a kernel feature on a given distribution.


> 
> 
> Going back to tomoyo.ko seen from my customers point of view.
> 
> Advantage of building TOMOYO into vmlinux is that the procedure for
> communicating with managers/developers/operators becomes simple.
> 
> Advantage of building TOMOYO as tomoyo.ko is that users can update only
> tomoyo.ko (thanks to KABI in RHEL kernels) when a bug is found in TOMOYO.
> Minimizing possible code changes helps minimizing cost for updating packages.
> But secure boot / module signing (not a topic to consider for current
> environment, but possibly becomes a topic to consider for future environment)
> needs to be taken into account.

Finally, I must admit that I know nearly nothing of both TOMOYO and BPF-LSM.
Nevertheless, for your tracing needs (this may not work well for enforcing a
policy, but I kind of inferred from your emails that you were mostly interested
in tracing/debugging capabilities), may you could reproduce the necessary functionalities
of TOMOYO via BPF-LSM?
I don't presume to know the complexity of that endeavor, nor how the limitations of
the ePBF verifier may make that partial rewrite difficult (and it certainly would be).
But it seems to me that you have three options:
- Get TOMOYO LKM merged, and wait a few years for it to be enabled by distros, readily
  available then deployed by your customers
- Pressure distributions into enabling TOMOYO (without the LKM), and wait a few years too
- Provide an eBPF program that can instrument LSM operations to extract the tracing information
  you need to debug your customers. You may also have to wait a few years to get the full
  feature set of TOMOYO working, or to get eventual missing features enabled in BPF-LSM, but
  a limited version may work on many kernels (even existing ones), and updates would be
  easier (not tied to a specific kernel version).

I am not saying that BPF-LSM is THE solution - it has too many limitations for that - but if
you desire to have a LSM for tracing needs (again, not for enforcement, where you cannot afford
to have a userland process load the BPF program) that you can update at will without rebooting,
that does not create new potential security issues (if we ignore speculative execution attacks
in eBPF), there is some appeal to that idea.

Simon

> 
> I'm not familiar with secure boot / module signing. I had a feeling that effectively
> only distributors can sign tomoyo.ko . But it seems that I can also sign tomoyo.ko
> if conditions are met. But I won't be able to provide infrastructure / support for
> problems related to secure boot, for I need to prepare copy-and-paste level
> procedure manual (not a snippet!) and support. tomoyo.ko being signed by
> distributors is much appreciated.
> 
> 

Re: TOMOYO's pull request for v6.12

[Dr. Greg]

On Sat, Oct 05, 2024 at 11:58:32AM -0700, Casey Schaufler wrote:

Hi, I hope the weekend is going well for everyone.

> On 10/5/2024 10:02 AM, Dr. Greg wrote:
> > On Sat, Oct 05, 2024 at 09:10:08AM -0700, Casey Schaufler wrote:
> >
> > Good morning to everyone, I hope the weekend is going well.
> >
> > I saw this go by while I was multi-tasking between draining the oil
> > out of the lower unit on my boat motor and welding the boat lift
> > canopy frame and wanted to make sure that Tetsuo's comment is
> > interpreted in the correct context.

> Playing with welders and petrochemicals at the same time is not
> recommended. Boom! Ack!

Actually 80/90 VIS gear lube isn't all that exciting, but we did have
some excitement.

Given that the 40 MPH sustained wind coming across the lake was making
MIG welding impossible [1], I drug the broken part of the lift into
the garage with the electric winch on my pickup and started welding on
it.  The MIG gun went dead and I flipped up my helmet to see what was
going on and my 95 year old Dad was leaning on his walker after
throwing the main breaker switch in the garage.

I told him he had ruined my bead and he said I had two five gallon
cans of gas sitting behind me.  I told him I had checked to make sure
the caps were on so we were good to go.

I haven't seen him that excited since Uncle Larry started welding on
the broken tongue of our homemade trailer that had three pallets of
gunpowder and a bunch of bee boxes on it that we had just hauled up
from Iowa [2].

> >> On 10/5/2024 12:10 AM, Tetsuo Handa wrote:
> >>> ... It is possible that an attempt to make it
> >>> possible to use SELinux and Smack together is a wrong direction. Even if SELinux
> >>> and TSEM conflicts about their security models (and cannot be used together), it
> >>> might not be something we need to care...
> >> In the past I have said that having SELinux and Smack on the same
> >> system is the test case for module stacking, but that I didn't see
> >> it having a practical application. I have since been presented with
> >> a use case that seems reasonable. Because LSM is a mechanism for
> >> additional restrictions it is impossible for two security models to
> >> "conflict". LSMs *must* be written to allow for cases where access
> >> is denied for other reasons. You never get to the MAC check if the
> >> DAC check has already failed. If TSEM can't handle what SELinux or
> >> TOMOYO decides it shouldn't be accepted.
> > I believe that Tetsuo misinterpreted the discussions you and I have
> > had about what represents a 'security model'.
> >
> > For the record, TSEM has no issue with handling whatever SeLinux,
> > SMACK, Tomoyo, AppArmor et.al. decide to do, full stop.
> >
> > It functions like all of the rest of the LSM modules, it determines
> > whether or not a security event is inconsistent with the 'model' that
> > the process is running in, and if so denies it, otherwise it stands
> > aside and lets the other LSM's have a run at it.
> >
> > If some other LSM in front of it decides to deny an event, well and
> > good, the event is over with from TSEM's perspective, as well as
> > anything else behind the denying LSM for that matter.
> >
> > You raised the issue, I believe in V1, as to where we had positioned
> > TSEM in the LSM call list.  After you expressed concern we moved it to
> > the front of the call list because we don't care and everyone else
> > seems to want to be later in the stack, particularly at the end, which
> > would now seem to be be a privileged position held only by BPF.
> >
> > To extend on this a bit for further clarification.
> >
> > As we have evolved TSEM we realized that we actually want to be first,
> > if that isn't also a coveted position.

> The current thought is that we frown on an LSM desiring a specific
> ordering and would probably reject one that required it.

As well we should.

Which is why TSEM has no interest in whether it is first, last,
fourth, sixth, ninth or somewhere else in between, we would embrace
someone choosing for us.

Our preference, only internally, for going first is that when TSEM is
in an infrastructure verification role, such as extended attribute
verification, and since the last time we checked first fail terminates
the LSM call chain, it seemed prudent with an eye on safety (we are
big on safety out here in the Upper Midwest) to bail as fast as we can
and issue a loud warning if there was evidence the LSM infrastructure
or integrity status of the operating system had been tampered with.

Casey, this is a time for you to have legendary impact on Linux
security, well beyond LSM stacking and SMACK, you choose for us... :-)

> > For example, internally, we have TSEM 'models' whose only function is
> > to validate that the extended security attributes of an inode match
> > what the workload was unit tested to, in order to thwart offline
> > modification attacks.  In this case you want TSEM to be running ahead
> > of the security attribute based models, since presumably, you would
> > not want those models making a decision on extended attributes that
> > have been modified.
> >
> > Hopefully this clarifies the issue.
> >
> > We have a long standing question, that has never been answered,
> > regarding module stacking and multiple MAC implementations on the same
> > OS instance but we will leave that to another conversation.

> I would be open to hearing which of the many open questions you're
> referring to.

It is no doubt a question that is simply secondary to our novitiate
status in all of this.

There was an LSM list thread started by, I believe a Korean Linux
integrator.  I believe they were on an Ubuntu OS base platform running
AppArmor and running a containerized Fedora implementation to
experiment with SeLinux, I don't remember all the details, the
exchange would be on lore.  They were somewhat disconcerted by the
fact that when they threw the switch on SeLinux in the Fedora
implementation things pretty much collapsed around them.

Paul replied back and said that the LSM doesn't know anything about
namespaces, so the impact of enabling SeLinux was OS wide.  He
commented further that the above scheme could be implemented but there
would have to be very sophisticated mutual exception policies in place
between the two modeling strategies and composing something like that
would be the domain of experts in the field.

I had replied back to Paul and indicated that it was our understanding
that with LSM stacking you get the union of all the implemented
security models.  We had posed the question, in this hypothetical, if
an unconfined system wide SeLinux policy would be needed to disallow
all action by SeLinux, except for subject/object interactions that
would occur in the subordinate OS instance, but I don't remember
seeing a response, we may have missed it.

Are we missing something in our interpretation of how this needs to
work?

Now off to cook sunfish for breakfast.

Have a good remainder of the weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity
              https://github.com/Quixote-Project

[1]: For those who pretty much only do computers.  I is largely
impossible to aluminum MIG weld in a high wind.  It disrupts the argon
shield gas flow and the molten aluminum reacts with the oxygen in the
air and forms aluminum oxide that cold caps the weld since the melting
point of aluminum oxide is higher than the melting point of the
aluminum base metal.

[2]: Yes, TSEM originates from a very rural part of America and we wear
that on our sleeves.

Re: TOMOYO's pull request for v6.12

[Casey Schaufler]

On 10/6/2024 9:18 AM, Dr. Greg wrote:
> On Sat, Oct 05, 2024 at 11:58:32AM -0700, Casey Schaufler wrote:
>
>
>> The current thought is that we frown on an LSM desiring a specific
>> ordering and would probably reject one that required it.
> As well we should.
>
> Which is why TSEM has no interest in whether it is first, last,
> fourth, sixth, ninth or somewhere else in between, we would embrace
> someone choosing for us.
>
> Our preference, only internally, for going first is that when TSEM is
> in an infrastructure verification role, such as extended attribute
> verification, and since the last time we checked first fail terminates
> the LSM call chain, it seemed prudent with an eye on safety (we are
> big on safety out here in the Upper Midwest) to bail as fast as we can
> and issue a loud warning if there was evidence the LSM infrastructure
> or integrity status of the operating system had been tampered with.
>
> Casey, this is a time for you to have legendary impact on Linux
> security, well beyond LSM stacking and SMACK, you choose for us... :-)

I'm not sure what you're asking. If you want my advice on where to
put TSEM in an LSM stack I'd say you should make sure that you really
don't care. Should a distro decide to (someday) include TSEM, they
are likely to have reasons of their own for assigning the LSM order.

>>> For example, internally, we have TSEM 'models' whose only function is
>>> to validate that the extended security attributes of an inode match
>>> what the workload was unit tested to, in order to thwart offline
>>> modification attacks.  In this case you want TSEM to be running ahead
>>> of the security attribute based models, since presumably, you would
>>> not want those models making a decision on extended attributes that
>>> have been modified.
>>>
>>> Hopefully this clarifies the issue.
>>>
>>> We have a long standing question, that has never been answered,
>>> regarding module stacking and multiple MAC implementations on the same
>>> OS instance but we will leave that to another conversation.
>> I would be open to hearing which of the many open questions you're
>> referring to.
> It is no doubt a question that is simply secondary to our novitiate
> status in all of this.
>
> There was an LSM list thread started by, I believe a Korean Linux
> integrator.  I believe they were on an Ubuntu OS base platform running
> AppArmor and running a containerized Fedora implementation to
> experiment with SeLinux, I don't remember all the details, the
> exchange would be on lore.  They were somewhat disconcerted by the
> fact that when they threw the switch on SeLinux in the Fedora
> implementation things pretty much collapsed around them.
>
> Paul replied back and said that the LSM doesn't know anything about
> namespaces, so the impact of enabling SeLinux was OS wide.  He
> commented further that the above scheme could be implemented but there
> would have to be very sophisticated mutual exception policies in place
> between the two modeling strategies and composing something like that
> would be the domain of experts in the field.
>
> I had replied back to Paul and indicated that it was our understanding
> that with LSM stacking you get the union of all the implemented
> security models.  We had posed the question, in this hypothetical, if
> an unconfined system wide SeLinux policy would be needed to disallow
> all action by SeLinux, except for subject/object interactions that
> would occur in the subordinate OS instance, but I don't remember
> seeing a response, we may have missed it.

Nested SELinux policies are the realm of SELinux namespaces, which are
currently a gleam in Steven Smalley's eye. There's a huge difference
between having multiple SELinux policies on a system and having one
SELinux policy and one AppArmor policy. The latter is much simpler.

> Are we missing something in our interpretation of how this needs to
> work?

Re: TOMOYO's pull request for v6.12

[Paul Moore]

On Sun, Oct 6, 2024 at 12:20 PM Dr. Greg <greg@enjellic.com> wrote:
>
> There was an LSM list thread started by, I believe a Korean Linux
> integrator.  I believe they were on an Ubuntu OS base platform running
> AppArmor and running a containerized Fedora implementation to
> experiment with SeLinux, I don't remember all the details, the
> exchange would be on lore.  They were somewhat disconcerted by the
> fact that when they threw the switch on SeLinux in the Fedora
> implementation things pretty much collapsed around them.
>
> Paul replied back and said that the LSM doesn't know anything about
> namespaces, so the impact of enabling SeLinux was OS wide.  He
> commented further that the above scheme could be implemented but there
> would have to be very sophisticated mutual exception policies in place
> between the two modeling strategies and composing something like that
> would be the domain of experts in the field.
>
> I had replied back to Paul and indicated that it was our understanding
> that with LSM stacking you get the union of all the implemented
> security models.  We had posed the question, in this hypothetical, if
> an unconfined system wide SeLinux policy would be needed to disallow
> all action by SeLinux, except for subject/object interactions that
> would occur in the subordinate OS instance, but I don't remember
> seeing a response, we may have missed it.

When multiple LSMs are enabled on a system the goal is for every
access decision to be only as permissive as the least permissive LSM.
This is a pattern seen in other places in the kernel as well,
including seccomp and the single LSM case when one considers the
combination of both the legacy DAC controls and the additional
controls implemented in the LSM.

The issue that sometimes confuses people is that there is no singular
LSM namespace mechanism implemented at the LSM framework level (that's
an intentional decision).  On a system that enables LSMs A and B, with
LSM A implementing a A-specific namespace, switching to a
second/child/etc. namespace in the A LSM does not mean you have
switched out of the B LSM; operations in the secondary A LSM namespace
must still satisfy the access control rules in the B LSM.

-- 
paul-moore.com

Re: TOMOYO's pull request for v6.12

[John Johansen]

On 10/6/24 13:20, Paul Moore wrote:
> On Sun, Oct 6, 2024 at 12:20 PM Dr. Greg <greg@enjellic.com> wrote:
>>
>> There was an LSM list thread started by, I believe a Korean Linux
>> integrator.  I believe they were on an Ubuntu OS base platform running
>> AppArmor and running a containerized Fedora implementation to
>> experiment with SeLinux, I don't remember all the details, the
>> exchange would be on lore.  They were somewhat disconcerted by the
>> fact that when they threw the switch on SeLinux in the Fedora
>> implementation things pretty much collapsed around them.
>>
>> Paul replied back and said that the LSM doesn't know anything about
>> namespaces, so the impact of enabling SeLinux was OS wide.  He
>> commented further that the above scheme could be implemented but there
>> would have to be very sophisticated mutual exception policies in place
>> between the two modeling strategies and composing something like that
>> would be the domain of experts in the field.
>>
>> I had replied back to Paul and indicated that it was our understanding
>> that with LSM stacking you get the union of all the implemented
>> security models.  We had posed the question, in this hypothetical, if
>> an unconfined system wide SeLinux policy would be needed to disallow
>> all action by SeLinux, except for subject/object interactions that
>> would occur in the subordinate OS instance, but I don't remember
>> seeing a response, we may have missed it.
> 
> When multiple LSMs are enabled on a system the goal is for every
> access decision to be only as permissive as the least permissive LSM.
> This is a pattern seen in other places in the kernel as well,
> including seccomp and the single LSM case when one considers the
> combination of both the legacy DAC controls and the additional
> controls implemented in the LSM.
> 
> The issue that sometimes confuses people is that there is no singular
> LSM namespace mechanism implemented at the LSM framework level (that's
> an intentional decision).  On a system that enables LSMs A and B, with
> LSM A implementing a A-specific namespace, switching to a
> second/child/etc. namespace in the A LSM does not mean you have
> switched out of the B LSM; operations in the secondary A LSM namespace
> must still satisfy the access control rules in the B LSM.
> 
Just Augmenting Paul's answer based on the original story of AppArmor
and SELinux. AppArmor internally support arbitrary stacking of its
policy with itself (what selinux was referring to as bounding), and
AppArmor supports policy namespacing.

This means its theoretically* possible to run an Ubuntu container using
apparmor on a fedora system that is using selinux. I was doing
presentations around this a few years ago. I think this actually led
to some confusion. I ran into several people who misunderstood the
apparmor presentations, and tried to do the inverse, but the inverse of
selinux in the container just isn't possible without work on selinux to
support it. Even if the LSM had a generic namespacing infrastructure,
individual LSMs would have to support it.

I do agree with Paul that there shouldn't be a single LSM framework for
namespacing (intentional), as different LSMs have different needs and
will need LSM module specific code to support it. But I do think the LSM
infrastructure could provide some additional support to an LSM so it
can provide namespacing. Like a security blob around namespacing, some
additional hooks, and a new lsm syscall or two.

Proposing something is still on my to do list, and I expect it will take
just as long as LSM stacking has to land something upstream.

* Theoretical because in addition to a custom kernel, it requires
   cooperation of the container manager to setup, and some modification
   of the selinux policy, and there is/was an issue around LSM interfaces
   (which require virtualization of the interface). In this situation
   AppArmor is enabled at the host level (which is required to track
   things correctly), but doesn't have a host policy installed. The
   container manager sets up the policy namespace which then allows the
   container to load a none host policy for the container.

   This whole situation requires both LSM stacking so apparmor and selinux
   can co-exist, and some kind of support for containerization on behalf
   of the lsm in the container.

Re: TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/06 20:14, Simon Thoby wrote:
>> It is sad that the LSM community does not like e.g. loadable LSM modules despite
>> writable variables are not a practical attack vector for my customers...
>>
> 
> The difficulty is that the LSM community need to think of what's best for all users,
> and that include users where the writable static calls may be an exploitable path.

I explained how __ro_after_init linked-list can be made writable only while registering
callbacks at https://lkml.kernel.org/r/5b09909b-fe43-4a9c-b9a7-2e1122b2cdb6@I-love.SAKURA.ne.jp .
What is the reason this approach can't be applied to __ro_after_init static calls?

I don't think that the LSM framework will forever never allow adding callbacks after
the __init phase. This is a matter of deciding whether the LSM framework allows
"making read-only a bit later the __init phase" (or "making writable only while
registering callbacks"). And if we decide to implement it, then we can write a
proper API.



>> Going back to tomoyo.ko seen from my customers point of view.
>>
>> Advantage of building TOMOYO into vmlinux is that the procedure for
>> communicating with managers/developers/operators becomes simple.
>>
>> Advantage of building TOMOYO as tomoyo.ko is that users can update only
>> tomoyo.ko (thanks to KABI in RHEL kernels) when a bug is found in TOMOYO.
>> Minimizing possible code changes helps minimizing cost for updating packages.
>> But secure boot / module signing (not a topic to consider for current
>> environment, but possibly becomes a topic to consider for future environment)
>> needs to be taken into account.
> 
> Finally, I must admit that I know nearly nothing of both TOMOYO and BPF-LSM.
> Nevertheless, for your tracing needs (this may not work well for enforcing a
> policy, but I kind of inferred from your emails that you were mostly interested
> in tracing/debugging capabilities), may you could reproduce the necessary functionalities
> of TOMOYO via BPF-LSM?

I already considered using BPF-LSM. My conclusion is that BPF-LSM is too
restricted to mimic TOMOYO's tracing capability.

Re: TOMOYO's pull request for v6.12

[Tetsuo Handa]

On 2024/10/05 12:38, John Johansen wrote:
> On 10/4/24 17:17, Kees Cook wrote:
>> (Out of curiosity, does RedHat build in AppArmor?)
>>
> 
> No they don't
> 

I think that AppArmor also has chance to get enabled in
at least Fedora kernels, for sending a pull request which
modifies kernel config options was accepted.

https://bugzilla.redhat.com/show_bug.cgi?id=2303689#c1
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3450

My goal is that TOMOYO is also enabled in RHEL kernels, as with
Landlock is currently trying.

https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3454