[LSM Stacking] SELinux policy inside container affects a process on Host

[Dr. Greg]

On Fri, Jul 07, 2023 at 05:28:36PM +0900, Leesoo Ahn wrote:

Hi Leesoo, I hope the week has gone well for you.

> 2023-07-06 ?????? 10:43??? Paul Moore ???(???) ??? ???:
> >On Thu, Jul 6, 2023 at 1:20???AM Leesoo Ahn <lsahn at wewakecorp.com> wrote:
> > >
> > > Hello! Here is another weird behavior of lsm stacking..
> > >
> > > test env
> > > - Ubuntu 23.04 Ubuntu Kernel v6.2 w/ Stacking patch v38
> > > - boot param: lsm=apparmor,selinux
> > > - AppArmor (Host) + SELinux (LXD Container Fedora 36)
> > >
> > > In the test environment mentioned above and applying selinux policy
> > > enforcing by running "setenforce 1" within the container, executing the
> > > following command on the host will result in "Permission denied" output.

> >SELinux operates independently of containers, or kernel namespacing in
> >general. When you load a SELinux policy it applies to all processes
> >on the system, regardless of where they are in relation to the process
> >which loaded the policy into the kernel.
> >
> >This behavior is independent of the LSM stacking work, you should be
> >able to see the same behavior even in cases where SELinux is the only
> >loaded LSM on the system.

> Thank you for the reply!
>
> So as far as I understand, the environment of LSM Stacking, AppArmor
> (Host) + SELinux (Container) couldn't provide features "using
> SELinux policy inside the container shouldn't affect to the host
> side" for now.
>
> If so, I wonder if you and Casey plan to design future features like
> that, because my co-workers and I are considering taking LSM
> stacking of AppArmor + SELinux in products that both policies must
> be working separately.

I see that Paul Moore has also replied and indicated that 'stacking'
doesn't imply either/or separation of security policy in a string of
LSM's.  As he also noted, it does not apply isolation and application
of security policy at the container or kernel resource namespace
level.

Just as an FYI, we will be releasing version 2 of our Trusted Security
Event Modeling (TSEM) LSM over the weekend for review and inclusion in
the upstream kernel.

TSEM 'stacks' with the other LSM's, but was architected from the
ground up to support the notion of security namespaces that operate
exclusively from one another, with the express goal of allowing
multiple and distinct security policies to be applied independently at
what would be considered the 'container' level.  Subordinate security
modeling namespaces also act independently from the security
model/policy that the 'root' modeling namespace is operating under.

TSEM is based on a mathematical modeling architecture that is
different from either the label or pathname based LSM's which allowed
us to sidestep some of the issues that are challenging with respect to
implementing full namespace support for those LSM's.

There is a sizable stack of documentation with TSEM that goes further
into all of this.  We also release a rather significant body of
userspace tooling that goes with the TSEM LSM to support running
'security containers', for lack of a better term.

It obviously takes a while to develop a security eco-system but TSEM
will hopefully offer security architects additional flexibility moving
forward.

> best regards,
> Leesoo

Have a good weekend.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity