TOMOYO's pull request for v6.12

[John Johansen]

On 10/6/24 13:20, Paul Moore wrote:
> 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.
> 
Just Augmenting Paul's answer based on the original story of AppArmor
and SELinux. AppArmor internally support arbitrary stacking of its
policy with itself (what selinux was referring to as bounding), and
AppArmor supports policy namespacing.

This means its theoretically* possible to run an Ubuntu container using
apparmor on a fedora system that is using selinux. I was doing
presentations around this a few years ago. I think this actually led
to some confusion. I ran into several people who misunderstood the
apparmor presentations, and tried to do the inverse, but the inverse of
selinux in the container just isn't possible without work on selinux to
support it. Even if the LSM had a generic namespacing infrastructure,
individual LSMs would have to support it.

I do agree with Paul that there shouldn't be a single LSM framework for
namespacing (intentional), as different LSMs have different needs and
will need LSM module specific code to support it. But I do think the LSM
infrastructure could provide some additional support to an LSM so it
can provide namespacing. Like a security blob around namespacing, some
additional hooks, and a new lsm syscall or two.

Proposing something is still on my to do list, and I expect it will take
just as long as LSM stacking has to land something upstream.

* Theoretical because in addition to a custom kernel, it requires
   cooperation of the container manager to setup, and some modification
   of the selinux policy, and there is/was an issue around LSM interfaces
   (which require virtualization of the interface). In this situation
   AppArmor is enabled at the host level (which is required to track
   things correctly), but doesn't have a host policy installed. The
   container manager sets up the policy namespace which then allows the
   container to load a none host policy for the container.

   This whole situation requires both LSM stacking so apparmor and selinux
   can co-exist, and some kind of support for containerization on behalf
   of the lsm in the container.