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

[Dr. Greg]

On Fri, Jul 28, 2023 at 10:54:23AM +0900, Leesoo Ahn wrote:

> I hope you have a great day today

Hi Leesoo, I hope your week is starting well.

> 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.

The most important issue in all of this is to understand that Linux
LSM's 'stack', they don't 'nest'.

If more than one LSM is enabled, their hooks will be called
consecutively until one fails or they all succeed.  There is currently
no concept of an 'LSM namespace' that would allow the actions of one
LSM to be isolated from a second LSM that is enabled.

So if you are attempting to run SELinux and AppArmor on the same host,
you need to reason through the effective security policy that results
from the combination of the SELinux and AppArmor policies.

We would certainly not profess to be the experts on LSM/SELinux that
Paul is but I believe the point he is making is that, in his opinion,
the only way to allow both policies to effectively co-habitate is to
use SELinux enforcement on the host system and AppArmor enforcement in
the container environment.

Lets see if we can reason through a hypothetical example that would
illustrate the issues involved.

If SELinux 'goes first', which will probably be the case, there will
be a need to have an SELinux policy in place that does not prohibit
the interaction of subjects and objects in the container environment,
otherwise you will get whatever the effective SELinux policy is.  Once
SELinux elects to not deny a security event, an AppArmor policy will
have the opportunity to make security decisions for the processes
running in the container environment.

As Casey has noted previously in this thread, creating this type of
environment will no doubt require some degree of sophistication and
expertise in both SELinux and AppArmor policy development and
implementation.

Hopefully the above will help facilitate further understanding with
respect to your efforts.

> Best regards,
> Leesoo

Best wishes for a productive remainder of the week and the success of
your work.

As always,
Dr. Greg

The Quixote Project - Flailing at the Travails of Cybersecurity