[LSM Stacking] SELinux policy inside container affects a processon Host

[Dr. Greg]

On Sun, Aug 06, 2023 at 03:25:32PM -0400, Paul Moore wrote:

Good morning, I hope the week has started well for everyone.

> On Sun, Aug 6, 2023 at 1:16???PM Dr. Greg <greg at enjellic.com> wrote:
> > On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote:
> > > 2023-07-07 ?????? 11:20??? Paul Moore ???(???) ??? ???:
> > > >On Fri, Jul 7, 2023 at 4:29???AM Leesoo Ahn <lsahn at wewakecorp.com> wrote:
> > >
> > > [...]
> > >
> > > >
> > > >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.
> > > >
> > > >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.
> > > >
> > > >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.
> >
> > > Paul, I don't get that SELinux on the host system and run AppArmor
> > > in the containers is the only practical solution. Could you please
> > > explain that in more details?
> >
> > It appears that Paul is extremely busy, so I thought the 'Quixote
> > Group' would try and offer some reflections that may help with your
> > efforts.

> My apologies, yes I am rather busy at the moment, but I also stopped
> following this thread a while ago as it didn't seem to be going
> anywhere meaningful.  I happen to read this last email while I'm
> waiting in an airport, so let me try and provide a quick explanation
> about why running SELinux only in a container is a bad idea.
> 
> As you probably know, the Linux kernel has no concept of a container,
> it only supports subsystem specific namespaces, e.g. mount namespace,
> network namespace, etc.  SELinux does not provide a subsystem
> namespace, and it does not generally concern itself with other
> subsystem names.  From a SELinux perspective there is no difference
> between a process running in the host namespace or a
> container/namespace; both are treated the same with access control
> decisions made based on the processes' SELinux domain, the type of the
> target resource, and the access requested.
> 
> If one were to load a SELinux policy inside a container, even if it
> were allowed, the system would likely behave in unexpected ways as the
> container-loaded policy will take effect across the entire system, not
> just inside the container.

All reasonable and consistent, with what we had previously written
with respect to there being no notion of LSM namespacing.

To further assist Leesoo and others who may be following this, you had
suggested the following earlier in this thread:

Paul> If you are interested in stacking SELinux and AppArmor, I
Paul> believe the only practical solution is to run SELinux on the
Paul> host system (initial namespace) and run AppArmor in the
Paul> containers.

Which would seem to apply that in a 'stacked' LSM configuration of
SELinux and AppArmor, there would be a possibility of using the two
LSM's without them 'colliding', the equivalent of what could be
considered a 'nested' LSM implementation.

Casey had also suggested in this thread that this would be possible at
the risk of a system that would be difficult to reason about.

Were our previous comments correct, that the path forward would be to
have SELinux configured in a manner where it would not act on any of
the subject/object interactions that occur in the container
environment that is using AppArmor?

If so, would the path forward be to implement an SELinux policy that
would place the process initiating the namespace, and its descendants,
in an unconfined domain with respect to the assets in the scope of the
container?

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity