[LSM Stacking] SELinux policy inside container affects a process on Host
Paul Moore
paul at paul-moore.com
Fri Jul 7 21:41:16 UTC 2023
On Fri, Jul 7, 2023 at 12:50 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 7/7/2023 7:20 AM, Paul Moore 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.
>
> 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.
The issue of namespacing LSMs is independent of stacking.
> > 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 remain unconvinced that namespacing should be done at the LSM layer;
my opinion is that namespacing should be handled individually by the
LSMs. Just as there is no single security model across LSMs, I don't
believe there should be a single approach to namespacing.
> > 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.
The concept of loading a separate SELinux policy into a container, and
having that policy apply only to that container, is not currently
possible. Of course there are ways to introduce additional security
domains within the container with SELinux, but that requires
cooperation between the container and the host. There are also
several different approaches available today for isolating containers
with SELinux, which tends to fit very well with most container
workloads, but I get the impression that is not what Leesoo is
interested in at the moment.
--
paul-moore.com
More information about the Linux-security-module-archive
mailing list