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: John Johansen <john.johansen@canonical.com>,
	LSM <linux-security-module@vger.kernel.org>,
	LKLM <linux-kernel@vger.kernel.org>,
	SE Linux <selinux@tycho.nsa.gov>,
	James Morris <jmorris@namei.org>, Eric Paris <eparis@redhat.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v13 0/9] LSM: Multiple concurrent LSMs
Date: Thu, 25 Apr 2013 11:01:50 -0400	[thread overview]
Message-ID: <47138397.PP25Tg7m1s@sifl> (raw)
In-Reply-To: <51787C1C.1040301@schaufler-ca.com>

On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
> On 4/24/2013 4:00 PM, John Johansen wrote:
> > On 04/24/2013 02:15 PM, Paul Moore wrote:
> >> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:

...

> >>> An interesting aside that may be relevant is that the error
> >>> condition behavior makes it advisable to have the LSM you care
> >>> about most go last. If the networking components were strictly
> >>> FCFS you might have to chose an ordering you might not want for
> >>> other reasons.
> >> 
> >> Well, maybe not ... I think.  If we take a FCFS approach to the network
> >> controls then only one LSM is really ever going to throw an error on the
> >> network hooks, yes?
> 
> You set up the order you want to get the networking handled
> correctly and you could get filesystem hooks in the wrong order.
> Not that that really ought to be a problem, but there are wonky
> admin tools out there.

I don't quite follow; can you be a bit more explicit about getting the 
filesystem hooks in the wrong order?

> >> I'm still in favor of assigning the network hooks to the LSM at boot
> >> based on the "security=" configuration.
> > 
> > yeah dealing with selection at boot time is going to be needed
> > at some point, whether its now or later ...
> 
> I'll have a go at it then. What that would mean is that:
> 
> 	security=smack,selinux
> 
> gives Smack NetLabel and SELinux xfrm and secmark while
> 
> 	security=selinux,smack
> 
> gives SELinux all three.

That seems reasonable, it also keeps the door open for adding a specific 
network hook ordering option, e.g. "security_net=", at a later date if 
necessary.

> I would still like it to be possible to explicitly configure the allocation
> at build time.

I suppose I have no object to that, I would just place my vote to have the 
dynamic FCFS (or LCFS if that makes more sense) assignment be the Kconfig 
default.

-- 
paul moore
www.paul-moore.com


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul@paul-moore.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: John Johansen <john.johansen@canonical.com>,
	LSM <linux-security-module@vger.kernel.org>,
	LKLM <linux-kernel@vger.kernel.org>,
	SE Linux <selinux@tycho.nsa.gov>,
	James Morris <jmorris@namei.org>, Eric Paris <eparis@redhat.com>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v13 0/9] LSM: Multiple concurrent LSMs
Date: Thu, 25 Apr 2013 11:01:50 -0400	[thread overview]
Message-ID: <47138397.PP25Tg7m1s@sifl> (raw)
In-Reply-To: <51787C1C.1040301@schaufler-ca.com>

On Wednesday, April 24, 2013 05:43:08 PM Casey Schaufler wrote:
> On 4/24/2013 4:00 PM, John Johansen wrote:
> > On 04/24/2013 02:15 PM, Paul Moore wrote:
> >> On Wednesday, April 24, 2013 01:22:20 PM Casey Schaufler wrote:

...

> >>> An interesting aside that may be relevant is that the error
> >>> condition behavior makes it advisable to have the LSM you care
> >>> about most go last. If the networking components were strictly
> >>> FCFS you might have to chose an ordering you might not want for
> >>> other reasons.
> >> 
> >> Well, maybe not ... I think.  If we take a FCFS approach to the network
> >> controls then only one LSM is really ever going to throw an error on the
> >> network hooks, yes?
> 
> You set up the order you want to get the networking handled
> correctly and you could get filesystem hooks in the wrong order.
> Not that that really ought to be a problem, but there are wonky
> admin tools out there.

I don't quite follow; can you be a bit more explicit about getting the 
filesystem hooks in the wrong order?

> >> I'm still in favor of assigning the network hooks to the LSM at boot
> >> based on the "security=" configuration.
> > 
> > yeah dealing with selection at boot time is going to be needed
> > at some point, whether its now or later ...
> 
> I'll have a go at it then. What that would mean is that:
> 
> 	security=smack,selinux
> 
> gives Smack NetLabel and SELinux xfrm and secmark while
> 
> 	security=selinux,smack
> 
> gives SELinux all three.

That seems reasonable, it also keeps the door open for adding a specific 
network hook ordering option, e.g. "security_net=", at a later date if 
necessary.

> I would still like it to be possible to explicitly configure the allocation
> at build time.

I suppose I have no object to that, I would just place my vote to have the 
dynamic FCFS (or LCFS if that makes more sense) assignment be the Kconfig 
default.

-- 
paul moore
www.paul-moore.com


  parent reply	other threads:[~2013-04-25 15:02 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5176ABB7.5080300@schaufler-ca.com>
2013-04-23 16:04 ` [PATCH v13 0/9] LSM: Multiple concurrent LSMs Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-24 18:57   ` Paul Moore
2013-04-24 18:57     ` Paul Moore
2013-04-24 20:22     ` Casey Schaufler
2013-04-24 20:22       ` Casey Schaufler
2013-04-24 21:15       ` Paul Moore
2013-04-24 21:15         ` Paul Moore
2013-04-24 23:00         ` John Johansen
2013-04-25  0:43           ` Casey Schaufler
2013-04-25  0:43             ` Casey Schaufler
2013-04-25 14:16             ` Tetsuo Handa
2013-04-25 15:01             ` Paul Moore [this message]
2013-04-25 15:01               ` Paul Moore
2013-04-25 18:09               ` Casey Schaufler
2013-04-25 18:09                 ` Casey Schaufler
2013-04-25 19:14                 ` Paul Moore
2013-04-25 19:14                   ` Paul Moore
2013-04-25 20:21                   ` Casey Schaufler
2013-04-25 20:21                     ` Casey Schaufler
2013-04-25 21:05                     ` Kees Cook
2013-04-25 21:26                     ` Paul Moore
2013-04-25 21:26                       ` Paul Moore
2013-04-23 16:04 ` [PATCH v13 1/9] LSM: Security blob abstraction Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 2/9] LSM: Complete conversion to kill_pid_info_as_cred Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 3/9] LSM: Multiple concurrent secids Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 4/9] LSM: Multiple security context maintenance Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 5/9] LSM: Networking component isolation Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-24 18:51   ` Paul Moore
2013-04-24 18:51     ` Paul Moore
2013-04-24 19:09     ` Casey Schaufler
2013-04-24 19:09       ` Casey Schaufler
2013-04-24 21:04       ` Paul Moore
2013-04-24 21:04         ` Paul Moore
2013-04-23 16:04 ` [PATCH v13 6/9] LSM: Additional interfaces in /proc/pid/attr Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 7/9] LSM: remove Yama special case stacking Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 20:12   ` Kees Cook
2013-04-23 16:04 ` [PATCH v13 8/9] LSM: Hook list management Casey Schaufler
2013-04-23 16:04   ` Casey Schaufler
2013-04-23 16:05 ` [PATCH v13 9/9] LSM: Documentation and cleanup Casey Schaufler
2013-04-23 16:05   ` Casey Schaufler
2013-04-23 19:02   ` Randy Dunlap

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=47138397.PP25Tg7m1s@sifl \
    --to=paul@paul-moore.com \
    --cc=casey@schaufler-ca.com \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=john.johansen@canonical.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=selinux@tycho.nsa.gov \
    /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.