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
next prev parent reply other threads:[~2013-04-25 15:07 UTC|newest]
Thread overview: 27+ 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-24 18:57 ` Paul Moore
2013-04-24 20:22 ` Casey Schaufler
2013-04-24 21:15 ` Paul Moore
2013-04-24 23:00 ` John Johansen
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 18:09 ` Casey Schaufler
2013-04-25 19:14 ` Paul Moore
2013-04-25 20:21 ` Casey Schaufler
2013-04-25 21:05 ` Kees Cook
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 ` [PATCH v13 2/9] LSM: Complete conversion to kill_pid_info_as_cred Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 3/9] LSM: Multiple concurrent secids Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 4/9] LSM: Multiple security context maintenance Casey Schaufler
2013-04-23 16:04 ` [PATCH v13 5/9] LSM: Networking component isolation Casey Schaufler
2013-04-24 18:51 ` Paul Moore
2013-04-24 19:09 ` Casey Schaufler
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 ` [PATCH v13 7/9] LSM: remove Yama special case stacking 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:05 ` [PATCH v13 9/9] LSM: Documentation and cleanup 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox