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