All of lore.kernel.org
 help / color / mirror / Atom feed
From: jmorris@namei.org (James Morris)
To: linux-security-module@vger.kernel.org
Subject: The secmark "one user" policy
Date: Fri, 23 Jun 2017 13:02:10 +1000 (AEST)	[thread overview]
Message-ID: <alpine.LRH.2.20.1706231257140.17128@namei.org> (raw)
In-Reply-To: <3baf4aae-6268-356b-8545-30655f561192@canonical.com>

On Thu, 22 Jun 2017, John Johansen wrote:

> > Trying to stack major LSMs arbitrarily and exposing that to userland is an 
> > architectural mess, which is what these kinds of problems are really 
> > telling us.
> > 
> 
> The use case I keep seeing is not exposing multiple LSMs to the user
> space. Its the container where the container wants a different LSM
> than the system is running.
> 
> Stacking 2 LSMs in that case and only exposing one to user space isn't
> so unreasonable.

In this case, would they both be labeling LSMs which need to label 
packets?

I can imagine having Smack or SELinux as the base LSM and then having 
AppArmor in the container, but having Smack and SELinux in that 
combination would still not make sense to me.

> 
> > How can a user be expected to reason about a system which is running 
> > multiple independent MAC security models simultaneously?  It's a terrible 
> > idea.
> > 
> 
> At a generic system MAC level I agree, but not all LSMs that need
> state are MACs and in the more limited container case it isn't so
> unreasonable.

Can you provide a concrete example of needing two independent packet 
labeling LSMs?


-- 
James Morris
<jmorris@namei.org>

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-06-23  3:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-21  0:41 The secmark "one user" policy Casey Schaufler
2017-06-21  7:13 ` James Morris
2017-06-21 15:23   ` Casey Schaufler
2017-06-21 23:07     ` John Johansen
2017-06-21 23:45       ` Casey Schaufler
2017-06-22  0:48         ` John Johansen
2017-06-22  9:54     ` James Morris
2017-06-22 16:17       ` Casey Schaufler
2017-06-23  3:12         ` James Morris
2017-06-23 15:26           ` Casey Schaufler
2017-06-25  9:41             ` James Morris
2017-06-25 18:05               ` Casey Schaufler
2017-06-26  7:54                 ` José Bollo
2017-06-26 15:10                   ` Casey Schaufler
2017-06-27 10:51                     ` José Bollo
2017-06-27 11:58                       ` Paul Moore
2017-06-22 18:49       ` John Johansen
2017-06-23  3:02         ` James Morris [this message]
2017-06-23  4:32           ` John Johansen
2017-06-29  9:10             ` James Morris
2017-06-29 16:46               ` John Johansen
2017-06-22 22:24     ` Paul Moore
2017-06-22 23:20       ` Casey Schaufler
2017-06-23 20:47         ` Paul Moore

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=alpine.LRH.2.20.1706231257140.17128@namei.org \
    --to=jmorris@namei.org \
    --cc=linux-security-module@vger.kernel.org \
    /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.