All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Leesoo Ahn <lsahn@wewakecorp.com>, linux-security-module@vger.kernel.org
Subject: Re: [LSM Stacking] SELinux policy inside container affects a process on Host
Date: Fri, 7 Jul 2023 17:41:16 -0400	[thread overview]
Message-ID: <CAHC9VhQeBomz1T5EUkdy_qKp9TbHDM=GSRqid9xqWGPeNGk82w@mail.gmail.com> (raw)
In-Reply-To: <67cb60c9-35c9-6dc3-7ef9-2540d5acf162@schaufler-ca.com>

On Fri, Jul 7, 2023 at 12:50 PM Casey Schaufler <casey@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

  reply	other threads:[~2023-07-07 21:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-06  5:12 [LSM Stacking] SELinux policy inside container affects a process on Host Leesoo Ahn
2023-07-06 13:43 ` Paul Moore
2023-07-07  0:35   ` Serge E. Hallyn
2023-07-07  1:17     ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn
2023-07-07  8:28   ` [LSM Stacking] SELinux policy inside container affects a process on Host Leesoo Ahn
2023-07-07 14:20     ` Paul Moore
2023-07-07 16:50       ` Casey Schaufler
2023-07-07 21:41         ` Paul Moore [this message]
2023-07-18 10:34         ` Dr. Greg
2023-07-18 17:20           ` Casey Schaufler
2023-07-19 18:45             ` Dr. Greg
2023-07-20  0:21               ` Casey Schaufler
2023-07-21 23:55                 ` Dr. Greg
2023-07-17 15:24       ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn
2023-07-17 15:51         ` Casey Schaufler
2023-07-24  2:29           ` [LSM Stacking] SELinux policy inside container affects aprocesson Host Leesoo Ahn
2023-07-24 21:35             ` Casey Schaufler
2023-07-25  3:16               ` [LSM Stacking] SELinux policy inside container affects aprocessonHost Leesoo Ahn
2023-07-28  1:54       ` [LSM Stacking] SELinux policy inside container affects a processon Host Leesoo Ahn
2023-08-06 17:16         ` Dr. Greg
2023-08-06 19:25           ` Paul Moore
2023-08-08  6:40             ` Dr. Greg
2023-08-08 14:32               ` Paul Moore
2023-07-07 17:51     ` [LSM Stacking] SELinux policy inside container affects a process on Host Dr. Greg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHC9VhQeBomz1T5EUkdy_qKp9TbHDM=GSRqid9xqWGPeNGk82w@mail.gmail.com' \
    --to=paul@paul-moore.com \
    --cc=casey@schaufler-ca.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lsahn@wewakecorp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.