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
>