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?