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

[Casey Schaufler]

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. 

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

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