From: Kees Cook <keescook@chromium.org>
To: John Johansen <john.johansen@canonical.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
James Morris <jmorris@namei.org>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
"Schaufler, Casey" <casey.schaufler@intel.com>,
LSM <linux-security-module@vger.kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH security-next v2 26/26] LSM: Add all exclusive LSMs to ordered initialization
Date: Thu, 20 Sep 2018 20:02:01 -0700 [thread overview]
Message-ID: <CAGXu5j+QhU2HOicYKqfNo17n9k6DKgt1upa3O2p1b5Gvn6icbQ@mail.gmail.com> (raw)
In-Reply-To: <74ecd4ec-491b-93d7-4e3f-46f92121130b@canonical.com>
On Thu, Sep 20, 2018 at 7:14 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 09/20/2018 07:05 PM, Kees Cook wrote:
>> On Thu, Sep 20, 2018 at 6:39 PM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>> On 09/20/2018 06:10 PM, Casey Schaufler wrote:
>>>> On 9/20/2018 5:45 PM, Kees Cook wrote:
>>>>> On Thu, Sep 20, 2018 at 5:25 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> On 9/20/2018 9:23 AM, Kees Cook wrote:
>>>>>>> config LSM_ORDER
>>>>>>> string "Default initialization order of builtin LSMs"
>>>>>>> - default "yama,loadpin,integrity"
>>>>>>> + default "yama,loadpin,integrity,selinux,smack,tomoyo,apparmor"
>>>>>> If I want to compile all the major modules into my kernel and use
>>>>>> AppArmor by default would I use
>>>>>>
>>>>>> default "yama,loadpin,integrity,apparmor,selinux,smack,tomoyo"
>>>>>>
>>>>>> or
>>>>>>
>>>>>> default "yama,loadpin,integrity,apparmor"
>>>>> I was expecting the former, but the latter will have the same result.
>>>
>>> t find having the two be equivalent violates expectations. At least
>>> when considering the end goal of full/extreme stacking, its trivially
>>> the same with current major lsms being exclusive
>>
>> This mixes "enablement" with "ordering", though, and I think the past
>> threads have shown this to be largely problematic.
>>
>> However, with CONFIG_LSM_ENABLED, we get the effect you're looking for, IIUC.
>
> no, I was just stating in a world where we have full stacking those two
> are not equivalent, as I would assume the order of any lsm not listed
> may end up being different.
Right, the ordering would be defined first by runtime (lsm.order=)
followed any missing LSMs then ordered by their order in
CONFIG_LSM_ORDER=, followed by any still missing LSMs then ordered by
their order at link-time (which *may* be Makefile order, but could
change with LTO, etc).
>>>>>> When we have "blob-sharing" how could I compile in tomoyo,
>>>>>> but exclude it without a boot line option?
>>>>> Ooh, yes, this series has no way to do that. Perhaps
>>>>> CONFIG_LSM_DISABLE in the same form as CONFIG_LSM_ORDER? I would
>>>>> totally remove LoadPin's CONFIG for this in favor it.
>>>>
>>>> I would generally prefer an optional CONFIG_LSM_ENABLE to
>>>> CONFIG_LSM_DISABLE, but I understand the logic behind your
>>>> approach. I would be looking for something like
>>>>
>>> +1 on the CONFIG_LSM_ENABLE ove DISABLE
>>>
>>>> CONFIG LSM_ENABLE
>>>> string "Default set of enabled LSMs"
>>>> default ""
>>>>
>>>> as opposed to
>>>>
>>>> CONFIG LSM_DISABLE
>>>> string "Default set of disabled LSMs"
>>>> default ""
>>>>
>>>> where an empty string is interpreted as "use 'em all"
>>>> in either case.
>>
>> Yes, I like CONFIG_LSM_ENABLE if "empty" means "enable all". Should
>> CONFIG_LSM_ENABLE replace all the other CONFIG-based LSM
>> enabling/disabling?
>
> I don't particularly like "empty" being "enable all". With that
> how would I disable all builtin lsms so that I just boot with
> capability.
>
> An option of all or even * is more explicit and leaves the empty
> set to mean disable everything
Okay, that works. I prefer "all" FWIW.
-Kees
--
Kees Cook
Pixel Security
WARNING: multiple messages have this Message-ID (diff)
From: keescook@chromium.org (Kees Cook)
To: linux-security-module@vger.kernel.org
Subject: [PATCH security-next v2 26/26] LSM: Add all exclusive LSMs to ordered initialization
Date: Thu, 20 Sep 2018 20:02:01 -0700 [thread overview]
Message-ID: <CAGXu5j+QhU2HOicYKqfNo17n9k6DKgt1upa3O2p1b5Gvn6icbQ@mail.gmail.com> (raw)
In-Reply-To: <74ecd4ec-491b-93d7-4e3f-46f92121130b@canonical.com>
On Thu, Sep 20, 2018 at 7:14 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 09/20/2018 07:05 PM, Kees Cook wrote:
>> On Thu, Sep 20, 2018 at 6:39 PM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>> On 09/20/2018 06:10 PM, Casey Schaufler wrote:
>>>> On 9/20/2018 5:45 PM, Kees Cook wrote:
>>>>> On Thu, Sep 20, 2018 at 5:25 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>>>>> On 9/20/2018 9:23 AM, Kees Cook wrote:
>>>>>>> config LSM_ORDER
>>>>>>> string "Default initialization order of builtin LSMs"
>>>>>>> - default "yama,loadpin,integrity"
>>>>>>> + default "yama,loadpin,integrity,selinux,smack,tomoyo,apparmor"
>>>>>> If I want to compile all the major modules into my kernel and use
>>>>>> AppArmor by default would I use
>>>>>>
>>>>>> default "yama,loadpin,integrity,apparmor,selinux,smack,tomoyo"
>>>>>>
>>>>>> or
>>>>>>
>>>>>> default "yama,loadpin,integrity,apparmor"
>>>>> I was expecting the former, but the latter will have the same result.
>>>
>>> t find having the two be equivalent violates expectations. At least
>>> when considering the end goal of full/extreme stacking, its trivially
>>> the same with current major lsms being exclusive
>>
>> This mixes "enablement" with "ordering", though, and I think the past
>> threads have shown this to be largely problematic.
>>
>> However, with CONFIG_LSM_ENABLED, we get the effect you're looking for, IIUC.
>
> no, I was just stating in a world where we have full stacking those two
> are not equivalent, as I would assume the order of any lsm not listed
> may end up being different.
Right, the ordering would be defined first by runtime (lsm.order=)
followed any missing LSMs then ordered by their order in
CONFIG_LSM_ORDER=, followed by any still missing LSMs then ordered by
their order at link-time (which *may* be Makefile order, but could
change with LTO, etc).
>>>>>> When we have "blob-sharing" how could I compile in tomoyo,
>>>>>> but exclude it without a boot line option?
>>>>> Ooh, yes, this series has no way to do that. Perhaps
>>>>> CONFIG_LSM_DISABLE in the same form as CONFIG_LSM_ORDER? I would
>>>>> totally remove LoadPin's CONFIG for this in favor it.
>>>>
>>>> I would generally prefer an optional CONFIG_LSM_ENABLE to
>>>> CONFIG_LSM_DISABLE, but I understand the logic behind your
>>>> approach. I would be looking for something like
>>>>
>>> +1 on the CONFIG_LSM_ENABLE ove DISABLE
>>>
>>>> CONFIG LSM_ENABLE
>>>> string "Default set of enabled LSMs"
>>>> default ""
>>>>
>>>> as opposed to
>>>>
>>>> CONFIG LSM_DISABLE
>>>> string "Default set of disabled LSMs"
>>>> default ""
>>>>
>>>> where an empty string is interpreted as "use 'em all"
>>>> in either case.
>>
>> Yes, I like CONFIG_LSM_ENABLE if "empty" means "enable all". Should
>> CONFIG_LSM_ENABLE replace all the other CONFIG-based LSM
>> enabling/disabling?
>
> I don't particularly like "empty" being "enable all". With that
> how would I disable all builtin lsms so that I just boot with
> capability.
>
> An option of all or even * is more explicit and leaves the empty
> set to mean disable everything
Okay, that works. I prefer "all" FWIW.
-Kees
--
Kees Cook
Pixel Security
next prev parent reply other threads:[~2018-09-21 3:02 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-20 16:23 [PATCH security-next v2 00/26] LSM: Explict LSM ordering Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 01/26] LSM: Correctly announce start of LSM initialization Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 23:39 ` Casey Schaufler
2018-09-20 23:39 ` Casey Schaufler
2018-09-20 16:23 ` [PATCH security-next v2 02/26] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 03/26] LSM: Rename .security_initcall section to .lsm_info Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 04/26] LSM: Remove initcall tracing Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 05/26] LSM: Convert from initcall to struct lsm_info Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 06/26] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 07/26] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 08/26] LSM: Record LSM name in struct lsm_info Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 09/26] LSM: Provide init debugging infrastructure Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 10/26] LSM: Don't ignore initialization failures Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 11/26] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 12/26] LSM: Provide separate ordered initialization Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 13/26] LSM: Plumb visibility into optional "enabled" state Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 14/26] LSM: Lift LSM selection out of individual LSMs Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 15/26] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 16/26] LSM: Prepare for reorganizing "security=" logic Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 17/26] LSM: Refactor "security=" in terms of enable/disable Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 18/26] LSM: Build ordered list of ordered LSMs for init Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-21 0:04 ` Casey Schaufler
2018-09-21 0:04 ` Casey Schaufler
2018-09-21 0:37 ` Kees Cook
2018-09-21 0:37 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 19/26] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-21 0:10 ` Casey Schaufler
2018-09-21 0:10 ` Casey Schaufler
2018-09-21 0:14 ` Casey Schaufler
2018-09-21 0:14 ` Casey Schaufler
2018-09-20 16:23 ` [PATCH security-next v2 20/26] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-21 0:12 ` Casey Schaufler
2018-09-21 0:12 ` Casey Schaufler
2018-09-21 0:40 ` Kees Cook
2018-09-21 0:40 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 21/26] LoadPin: Initialize as ordered LSM Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 22/26] Yama: " Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 23/26] LSM: Introduce enum lsm_order Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 24/26] capability: Mark as LSM_ORDER_FIRST Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 25/26] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-20 16:23 ` [PATCH security-next v2 26/26] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
2018-09-20 16:23 ` Kees Cook
2018-09-21 0:25 ` Casey Schaufler
2018-09-21 0:25 ` Casey Schaufler
2018-09-21 0:45 ` Kees Cook
2018-09-21 0:45 ` Kees Cook
2018-09-21 1:10 ` Casey Schaufler
2018-09-21 1:10 ` Casey Schaufler
2018-09-21 1:39 ` John Johansen
2018-09-21 1:39 ` John Johansen
2018-09-21 2:05 ` Kees Cook
2018-09-21 2:05 ` Kees Cook
2018-09-21 2:14 ` John Johansen
2018-09-21 2:14 ` John Johansen
2018-09-21 3:02 ` Kees Cook [this message]
2018-09-21 3:02 ` Kees Cook
2018-09-21 13:19 ` John Johansen
2018-09-21 13:19 ` John Johansen
2018-09-21 14:57 ` Casey Schaufler
2018-09-21 14:57 ` Casey Schaufler
2018-09-20 20:14 ` [PATCH security-next v2 00/26] LSM: Explict LSM ordering Martin Steigerwald
2018-09-20 20:14 ` Martin Steigerwald
2018-09-20 21:55 ` Kees Cook
2018-09-20 21:55 ` Kees Cook
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=CAGXu5j+QhU2HOicYKqfNo17n9k6DKgt1upa3O2p1b5Gvn6icbQ@mail.gmail.com \
--to=keescook@chromium.org \
--cc=casey.schaufler@intel.com \
--cc=casey@schaufler-ca.com \
--cc=corbet@lwn.net \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=sds@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.