TOMOYO's pull request for v6.12

[Paul Moore]

On Sun, Oct 6, 2024 at 12:20 PM Dr. Greg <greg at 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