linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul@paul-moore.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: James Morris <jmorris@namei.org>, Steve Grubb <sgrubb@redhat.com>,
	Richard Guy Briggs <rgb@redhat.com>,
	"linux-audit@redhat.com" <linux-audit@redhat.com>,
	Linux Security Module list 
	<linux-security-module@vger.kernel.org>
Subject: Re: Preferred subj= with multiple LSMs
Date: Mon, 22 Jul 2019 18:30:35 -0400	[thread overview]
Message-ID: <CAHC9VhSbg7BxPSA4NkQV3_1zx6cj3ej25e6fJ2FBWX9fU104rg@mail.gmail.com> (raw)
In-Reply-To: <ca22ea45-3f3b-4f79-8d77-7528877b8b36@schaufler-ca.com>

On Mon, Jul 22, 2019 at 6:01 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 7/22/2019 1:50 PM, James Morris wrote:
> > On Fri, 19 Jul 2019, Paul Moore wrote:
> >
> >>> We've never had to think about having general rules on
> >>> what security modules do before, because with only one
> >>> active each could do whatever it wanted without fear of
> >>> conflict. If there is already a character that none of
> >>> the existing modules use, how would it be wrong to
> >>> reserve it?
> >> "We've never had to think about having general rules on what security
> >> modules do before..."
> >>
> >> We famously haven't imposed restrictions on the label format before
> >> now, and this seems like a pretty poor reason to start.
> > Agreed.
>
> In a follow on thread
>
> https://www.spinics.net/lists/linux-security-module/msg29996.html
>
> we've been discussing the needs of dbus-daemon in a multiple LSM
> environment. I suggest that if supporting dbus well is assisted by
> making reasonable restrictions on what constitutes a valid LSM
> "context" that we have a good reason. While there are ways to
> present groups of arbitrary hunks of data, why would we want to?

I continue to believe that restrictions on the label format are a bad
idea, and I further believe that multiplexing the labels is going to
be a major problem that will haunt us for many, many years.  If we are
going to support multiple simultaneous LSMs I think we need to find a
way to represent those labels independently.

-- 
paul moore
www.paul-moore.com

  reply	other threads:[~2019-07-22 22:30 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-12 16:33 Preferred subj= with multiple LSMs Casey Schaufler
     [not found] ` <c46932ec-e38e-ba15-7ceb-70e0fe0ef5dc@schaufler-ca.com>
2019-07-13 15:08 ` Steve Grubb
2019-07-15 19:04   ` Richard Guy Briggs
     [not found] ` <1979804.kRvuSoDnao@x2>
     [not found]   ` <2802ddee-b621-c2eb-9ff3-ea15c4f19d0c@schaufler-ca.com>
     [not found]     ` <3577098.oGDFHdoSSQ@x2>
2019-07-16 17:16       ` Casey Schaufler
     [not found]   ` <CAHC9VhSELVZN8feH56zsANqoHu16mPMD04Ww60W=r6tWs+8WnQ@mail.gmail.com>
2019-07-16 17:29     ` Casey Schaufler
2019-07-16 17:43       ` Paul Moore
2019-07-16 17:58         ` Casey Schaufler
2019-07-16 18:06         ` Steve Grubb
2019-07-16 18:41           ` Casey Schaufler
2019-07-16 21:25             ` Paul Moore
2019-07-16 21:46               ` Steve Grubb
2019-07-16 22:18                 ` Casey Schaufler
2019-07-16 23:13                   ` Paul Moore
2019-07-16 23:47                     ` Casey Schaufler
2019-07-17 12:14                       ` Paul Moore
2019-07-17 15:49                         ` Casey Schaufler
2019-07-17 16:23                           ` Paul Moore
2019-07-17 23:02                             ` Casey Schaufler
2019-07-18 13:10                               ` Simon McVittie
2019-07-18 16:13                                 ` Casey Schaufler
2019-07-19 12:15                                   ` Simon McVittie
2019-07-19 16:29                                     ` Casey Schaufler
2019-07-19 18:47                                       ` Simon McVittie
2019-07-19 20:02                                         ` Dbus and multiple LSMs (was Preferred subj= with multiple LSMs) Casey Schaufler
2019-07-22 11:36                                           ` Simon McVittie
2019-07-22 16:04                                             ` Casey Schaufler
2019-07-19 21:21                               ` Preferred subj= with multiple LSMs Paul Moore
2019-07-22 20:50                                 ` James Morris
2019-07-22 22:01                                   ` Casey Schaufler
2019-07-22 22:30                                     ` Paul Moore [this message]
2019-07-23  0:11                                       ` Casey Schaufler
2019-07-23 14:06                                       ` Simon McVittie
2019-07-23 17:32                                         ` Casey Schaufler
2019-07-23 21:46                                         ` James Morris
2019-07-16 23:09                 ` Paul Moore
2019-07-17  4:36                   ` James Morris
2019-07-17 12:23                     ` Paul Moore
2019-07-18 15:01               ` William Roberts
2019-07-18 18:48                 ` Casey Schaufler

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=CAHC9VhSbg7BxPSA4NkQV3_1zx6cj3ej25e6fJ2FBWX9fU104rg@mail.gmail.com \
    --to=paul@paul-moore.com \
    --cc=casey@schaufler-ca.com \
    --cc=jmorris@namei.org \
    --cc=linux-audit@redhat.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=rgb@redhat.com \
    --cc=sgrubb@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).