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

[Dr. Greg]

On Fri, Jul 07, 2023 at 09:50:41AM -0700, Casey Schaufler wrote:

Hi, I hope the week is going well for everyone.

> On 7/7/2023 7:20 AM, Paul Moore wrote:
> > On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn at wewakecorp.com> wrote:
> >> 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.

> > What you are looking for is a combination of LSM stacking and
> > individual LSM namespacing.  Sadly, I think the communications
> > around LSM stacking have not been very clear on this and I worry
> > that many people are going to be disappointed with LSM stacking
> > for this very reason.

> There have been many discussions regarding the viability of the
> using different LSM policies in containers. Some of these
> discussions have been quite lively. I have never claimed that LSM
> stacking addresses all of the possible use cases for multiple
> concurrent LSMs. If people are disappointed by how little they can
> accomplish with what is currently being proposed I can only say that
> we can't get on to the next phase until this work is complete.

It seems pretty clear, to us anyway, that generic user expectations
are that advanced security controls for Linux, ie beyond DAC, should
provide the same compartmentalization and isolation that other
resource namespaces bring to the table.  The 10 years of experience we
have had with building systems, and feedback we have received from
collaborators with significant experience in critical infrastructure,
drove the focus in TSEM on strictly partitioned and workload based
security controls.

We obviously had an advantage in that we came into this with the
opportunity for a clean design, whereas the existing, particularly
label based solutions, have the constraint of a single ground truth
with respect to the inode label implemented in the extended
attributes.  Which is the fault of nobody, but rather a function of
the fact that label based systems have a heritage from before anyone
even thought about resource namespaces.

Do to our objectives, and the approach we took, TSEM doesn't require
support for 'stacking' with other LSM's, obviously other LSM's do need
that support, not a criticism but an observation.  That opened the
door to implement what users would consider to be an independent
security namespace.

The take away, that I assume everyone interested in Linux security
would be in agreement on, perhaps not, is that user expectations are
to have independent and separately administered security control
environments that don't interact with one another.

> > While stacking of LSMs is largely done at the LSM layer, namespacing
> > LSMs such that they can be customized for individual containers
> > requires work to be done at the per-LSM level as each LSM is
> > different.  AppArmor already has a namespacing concept, but SELinux
> > does not.  Due to differences in the approach taken by the two LSMs,
> > namespacing is much more of a challenge for SELinux, largely due to
> > issues around filesystem labeling.  We have not given up on the idea,
> > but we have yet to arrive at a viable solution for namespacing
> > SELinux.

> I remain more optimistic than Paul about the options for supporting
> generic LSM namespacing. I hope to explore a couple notions that I
> have more fully, but as they depend on the current stacking work I
> may not get to them very soon.

I believe TSEM demonstrates that we already have the infrastructure at
the LSM layer for generic namespacing.  Of all the current LSM's, I
believe we have the most sophisticated namespace implementation with
respect to the functionality that it implements.

We have implemented TSEM using both the standard Linux namespace
infrastructure and as an independent namespace implementation using
the LSM 'blob' infrastructure.  FWIW, we have never looked back on the
decision to implement LSM specific namespacing using the generic LSM
'blob' functionality.

If there is a desire to provide some minimum level of generic security
namespace functionality I could recitate a whole list of thoughts to
consider but will leave that to another time.

> > If you are interested in stacking SELinux and AppArmor, I believe the
> > only practical solution is to run SELinux on the host system (initial
> > namespace) and run AppArmor in the containers.  Even in a world where
> > SELinux is fully namespaced, it would likely still be necessary to run
> > some type of SELinux policy on the host (initial namespace) in order
> > to support SELinux policies in the containers.

> SELinux policy is sufficiently flexible to support what would look
> like different policies on the host system and in the container. I
> think that the administration of such a system would be tricky, and
> the policy would be very complex, but it could be done, for some use
> cases at least.

These reflections illuminate our motivation in developing TSEM, others
may disagree, but a lot of experience in, and observation of, the
security industry has led us to believe that security has to get
simpler and easier to implement rather than more complex and arcane.

We are probably at an interesting juncture in Linux development.  The
security controls we make available as a platform can either pursue a
path where only highly skilled administrators and technology companies
can implement them, or, we can provide mechanisms that work to increase
the accessibility by development teams and ultimately the user
community to advanced security controls.

With TSEM, our design philosophy is that security controls need to
flow from the development process in order to accomplish this latter
objective.  CI/CD is now considered a necessary and standard practice
in the software industry, it doesn't seem like a stretch of the
imagination that security controls should flow from that process as
well.

One of the requirements of this model is the ability to strictly scope
security controls to the level of a workload nee security modeling
namespace.

Regardless of motivation, it would seem from this thread alone, that
there is a user expectation, if not a necessary technical requirement,
for Linux to provide infrastructure that enables strictly partitioned
and independent security controls that don't require extensive
reasoning as to what they might actually do in practice.

Have a good week.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity