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.