Re: Linux 5.1-rc2

Re: Linux 5.1-rc2

[Randy Dunlap]

On 3/24/19 2:26 PM, Linus Torvalds wrote:
> Well, we're a week away from the merge window close, and here's rc2.
> Things look fairly normal, but honestly, rc2 is usually too early to
> tell.  People haven't necessarily had time to notice problems yet.
> Which is just another way of saying "please test harder".
> 
> Nothing particularly stands out. Yes, we had some fixes for the new
> io_ring code for issues that were discussed when merging it. Other
> than that, worth noting is that the bulk of the patches are for
> tooling, not the core kernel. In fact, about two thirds of the patch
> is just for the tools/ subdirectory, most of it due to some late perf
> tool updates. The people involved promise they're done.

Hmph.  I'm still looking for the patch that restores the various
CONFIG_DEFAULT_<security> kconfig options to be merged.

https://lore.kernel.org/linux-security-module/2bf23acd-22c4-a260-7648-845887a409d5@i-love.sakura.ne.jp/

since commit 70b62c25665f636c9f6c700b26af7df296b0887e dropped them somehow.


-- 
~Randy

Re: Linux 5.1-rc2

[James Morris]

On Sun, 24 Mar 2019, Randy Dunlap wrote:

> On 3/24/19 2:26 PM, Linus Torvalds wrote:
> > Well, we're a week away from the merge window close, and here's rc2.
> > Things look fairly normal, but honestly, rc2 is usually too early to
> > tell.  People haven't necessarily had time to notice problems yet.
> > Which is just another way of saying "please test harder".
> > 
> > Nothing particularly stands out. Yes, we had some fixes for the new
> > io_ring code for issues that were discussed when merging it. Other
> > than that, worth noting is that the bulk of the patches are for
> > tooling, not the core kernel. In fact, about two thirds of the patch
> > is just for the tools/ subdirectory, most of it due to some late perf
> > tool updates. The people involved promise they're done.
> 
> Hmph.  I'm still looking for the patch that restores the various
> CONFIG_DEFAULT_<security> kconfig options to be merged.
> 
> https://lore.kernel.org/linux-security-module/2bf23acd-22c4-a260-7648-845887a409d5@i-love.sakura.ne.jp/
> 
> since commit 70b62c25665f636c9f6c700b26af7df296b0887e dropped them somehow.

AFAICT we don't have a finalized version of the patch yet.

Kees?


-- 
James Morris
<jmorris@namei.org>

Re: Linux 5.1-rc2

[Tetsuo Handa]

On 2019/03/26 4:08, James Morris wrote:
> On Sun, 24 Mar 2019, Randy Dunlap wrote:
> 
>> On 3/24/19 2:26 PM, Linus Torvalds wrote:
>>> Well, we're a week away from the merge window close, and here's rc2.
>>> Things look fairly normal, but honestly, rc2 is usually too early to
>>> tell.  People haven't necessarily had time to notice problems yet.
>>> Which is just another way of saying "please test harder".
>>>
>>> Nothing particularly stands out. Yes, we had some fixes for the new
>>> io_ring code for issues that were discussed when merging it. Other
>>> than that, worth noting is that the bulk of the patches are for
>>> tooling, not the core kernel. In fact, about two thirds of the patch
>>> is just for the tools/ subdirectory, most of it due to some late perf
>>> tool updates. The people involved promise they're done.
>>
>> Hmph.  I'm still looking for the patch that restores the various
>> CONFIG_DEFAULT_<security> kconfig options to be merged.
>>
>> https://lore.kernel.org/linux-security-module/2bf23acd-22c4-a260-7648-845887a409d5@i-love.sakura.ne.jp/
>>
>> since commit 70b62c25665f636c9f6c700b26af7df296b0887e dropped them somehow.
> 
> AFAICT we don't have a finalized version of the patch yet.
> 
> Kees?
> 

As far as I can tell, Kees's comment

  It breaks the backward-compat for the "security=" line. If a system is
  booted with CONFIG_LSM="minors...,apparmor" and "security=selinux",
  neither apparmor nor selinux will be initialized. The logic on
  "security=..." depends on the other LSMs being present in the list.

was just a confusion, and I think that this version can become
the finalized version.

From 72f5f21b800c87f9ec3600f6e3acfb654690d8f0 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Tue, 26 Mar 2019 05:56:30 +0900
Subject: [PATCH] LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"

Commit 70b62c25665f636c ("LoadPin: Initialize as ordered LSM") removed
CONFIG_DEFAULT_SECURITY_{SELINUX,SMACK,TOMOYO,APPARMOR,DAC} from
security/Kconfig and changed CONFIG_LSM to provide a fixed ordering as a
default value. That commit expected that existing users (upgrading from
Linux 5.0 and earlier) will edit CONFIG_LSM value in accordance with
their CONFIG_DEFAULT_SECURITY_* choice in their old kernel configs. But
since users might forget to edit CONFIG_LSM value, this patch revives
the choice (only for providing the default value for CONFIG_LSM) in order
to make sure that CONFIG_LSM reflects CONFIG_DEFAULT_SECURITY_* from their
old kernel configs.

Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/Kconfig | 37 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/security/Kconfig b/security/Kconfig
index 1d6463f..2f29805 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -239,9 +239,44 @@ source "security/safesetid/Kconfig"
 
 source "security/integrity/Kconfig"
 
+choice
+	prompt "Default security module [superseded by 'Ordered list of enabled LSMs' below]"
+	default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX
+	default DEFAULT_SECURITY_SMACK if SECURITY_SMACK
+	default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO
+	default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR
+	default DEFAULT_SECURITY_DAC
+
+	help
+	  This choice is there only for converting CONFIG_DEFAULT_SECURITY in old
+	  kernel config to CONFIG_LSM in new kernel config. Don't change this choice
+	  unless you are creating a fresh kernel config, for this choice will be
+	  ignored after CONFIG_LSM is once defined.
+
+	config DEFAULT_SECURITY_SELINUX
+		bool "SELinux" if SECURITY_SELINUX=y
+
+	config DEFAULT_SECURITY_SMACK
+		bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y
+
+	config DEFAULT_SECURITY_TOMOYO
+		bool "TOMOYO" if SECURITY_TOMOYO=y
+
+	config DEFAULT_SECURITY_APPARMOR
+		bool "AppArmor" if SECURITY_APPARMOR=y
+
+	config DEFAULT_SECURITY_DAC
+		bool "Unix Discretionary Access Controls"
+
+endchoice
+
 config LSM
 	string "Ordered list of enabled LSMs"
-	default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
+	default "yama,loadpin,safesetid,integrity,selinux" if DEFAULT_SECURITY_SELINUX
+	default "yama,loadpin,safesetid,integrity,smack" if DEFAULT_SECURITY_SMACK
+	default "yama,loadpin,safesetid,integrity,tomoyo" if DEFAULT_SECURITY_TOMOYO
+	default "yama,loadpin,safesetid,integrity,apparmor" if DEFAULT_SECURITY_APPARMOR
+	default "yama,loadpin,safesetid,integrity"
 	help
 	  A comma-separated list of LSMs, in initialization order.
 	  Any LSMs left off this list will be ignored. This can be
-- 
1.8.3.1

Re: Linux 5.1-rc2

[Kees Cook]

On Mon, Mar 25, 2019 at 2:06 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2019/03/26 4:08, James Morris wrote:
> > On Sun, 24 Mar 2019, Randy Dunlap wrote:
> >
> >> On 3/24/19 2:26 PM, Linus Torvalds wrote:
> >>> Well, we're a week away from the merge window close, and here's rc2.
> >>> Things look fairly normal, but honestly, rc2 is usually too early to
> >>> tell.  People haven't necessarily had time to notice problems yet.
> >>> Which is just another way of saying "please test harder".
> >>>
> >>> Nothing particularly stands out. Yes, we had some fixes for the new
> >>> io_ring code for issues that were discussed when merging it. Other
> >>> than that, worth noting is that the bulk of the patches are for
> >>> tooling, not the core kernel. In fact, about two thirds of the patch
> >>> is just for the tools/ subdirectory, most of it due to some late perf
> >>> tool updates. The people involved promise they're done.
> >>
> >> Hmph.  I'm still looking for the patch that restores the various
> >> CONFIG_DEFAULT_<security> kconfig options to be merged.
> >>
> >> https://lore.kernel.org/linux-security-module/2bf23acd-22c4-a260-7648-845887a409d5@i-love.sakura.ne.jp/
> >>
> >> since commit 70b62c25665f636c9f6c700b26af7df296b0887e dropped them somehow.
> >
> > AFAICT we don't have a finalized version of the patch yet.
> >
> > Kees?

Sorry for the delay -- back from travel now.

> As far as I can tell, Kees's comment
>
>   It breaks the backward-compat for the "security=" line. If a system is
>   booted with CONFIG_LSM="minors...,apparmor" and "security=selinux",
>   neither apparmor nor selinux will be initialized. The logic on
>   "security=..." depends on the other LSMs being present in the list.
>
> was just a confusion

Yes, you are correct here. This is what I get for drive-by comments
while travelling. :) However, I don't like that it creates an
incomplete LSM list for no reason. I'd like CONFIG_LSM to be built in
a way that future stack-enabling will Just Work. Leaving off LSMs
means it won't. My original patch doesn't change the behavior relative
to the old configs (i.e. the CONFIG_DEFAULT_SECURITY_* will still be
selected and turn off the others) but does allow the other LSMs to be
initialized in the future once earlier ones in the list become
stackable.

The part I don't understand is what you've said about TOMOYO being
primary and not wanting the others stackable? That kind of goes
against the point, but I'm happy to do that if you want it that way.
If so, my current proposal would be:

 config LSM
        string "Ordered list of enabled LSMs"
+       default
"yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor" if
DEFAULT_SECURITY_SMACK
+       default
"yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" if
DEFAULT_SECURITY_APPARMOR
+       default "yama,loadpin,safesetid,integrity,tomoyo" if
DEFAULT_SECURITY_TOMOYO
+       default "yama,loadpin,safesetid,integrity" if DEFAULT_SECURITY_DAC
        default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"

Note that the last default line holds for both "new build" and
"selinux chosen". The other change from my earlier patch is that _DAC
must turn off all the legacy major LSMs to get the behavior Randy was
expecting. Shall I send a patch that does the above, or is there
another wrinkle?

Thanks!

-Kees

> the finalized version.
>
> From 72f5f21b800c87f9ec3600f6e3acfb654690d8f0 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Tue, 26 Mar 2019 05:56:30 +0900
> Subject: [PATCH] LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"
>
> Commit 70b62c25665f636c ("LoadPin: Initialize as ordered LSM") removed
> CONFIG_DEFAULT_SECURITY_{SELINUX,SMACK,TOMOYO,APPARMOR,DAC} from
> security/Kconfig and changed CONFIG_LSM to provide a fixed ordering as a
> default value. That commit expected that existing users (upgrading from
> Linux 5.0 and earlier) will edit CONFIG_LSM value in accordance with
> their CONFIG_DEFAULT_SECURITY_* choice in their old kernel configs. But
> since users might forget to edit CONFIG_LSM value, this patch revives
> the choice (only for providing the default value for CONFIG_LSM) in order
> to make sure that CONFIG_LSM reflects CONFIG_DEFAULT_SECURITY_* from their
> old kernel configs.
>
> Reported-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Acked-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
>  security/Kconfig | 37 ++++++++++++++++++++++++++++++++++++-
>  1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/security/Kconfig b/security/Kconfig
> index 1d6463f..2f29805 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -239,9 +239,44 @@ source "security/safesetid/Kconfig"
>
>  source "security/integrity/Kconfig"
>
> +choice
> +       prompt "Default security module [superseded by 'Ordered list of enabled LSMs' below]"
> +       default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX
> +       default DEFAULT_SECURITY_SMACK if SECURITY_SMACK
> +       default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO
> +       default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR
> +       default DEFAULT_SECURITY_DAC
> +
> +       help
> +         This choice is there only for converting CONFIG_DEFAULT_SECURITY in old
> +         kernel config to CONFIG_LSM in new kernel config. Don't change this choice
> +         unless you are creating a fresh kernel config, for this choice will be
> +         ignored after CONFIG_LSM is once defined.
> +
> +       config DEFAULT_SECURITY_SELINUX
> +               bool "SELinux" if SECURITY_SELINUX=y
> +
> +       config DEFAULT_SECURITY_SMACK
> +               bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y
> +
> +       config DEFAULT_SECURITY_TOMOYO
> +               bool "TOMOYO" if SECURITY_TOMOYO=y
> +
> +       config DEFAULT_SECURITY_APPARMOR
> +               bool "AppArmor" if SECURITY_APPARMOR=y
> +
> +       config DEFAULT_SECURITY_DAC
> +               bool "Unix Discretionary Access Controls"
> +
> +endchoice
> +
>  config LSM
>         string "Ordered list of enabled LSMs"
> -       default "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
> +       default "yama,loadpin,safesetid,integrity,selinux" if DEFAULT_SECURITY_SELINUX
> +       default "yama,loadpin,safesetid,integrity,smack" if DEFAULT_SECURITY_SMACK
> +       default "yama,loadpin,safesetid,integrity,tomoyo" if DEFAULT_SECURITY_TOMOYO
> +       default "yama,loadpin,safesetid,integrity,apparmor" if DEFAULT_SECURITY_APPARMOR
> +       default "yama,loadpin,safesetid,integrity"
>         help
>           A comma-separated list of LSMs, in initialization order.
>           Any LSMs left off this list will be ignored. This can be
> --
> 1.8.3.1



-- 
Kees Cook

Re: Linux 5.1-rc2

[Tetsuo Handa]

On 2019/03/28 4:16, Kees Cook wrote:
> The part I don't understand is what you've said about TOMOYO being
> primary and not wanting the others stackable? That kind of goes
> against the point, but I'm happy to do that if you want it that way.

Automatically enabling multiple legacy major LSMs might result in a confusion like
Jakub encountered. For a few releases from 5.1 (about one year or so?), since
CONFIG_DEFAULT_SECURITY_* will be ignored after CONFIG_LSM is once defined in
their kernel configs, I guess that it is better not to enable TOMOYO automatically
until most people complete migrating from CONFIG_DEFAULT_SECURITY_* to CONFIG_LSM
and get used to use lsm= kernel command line option rather than security= kernel
command line option.

Re: Linux 5.1-rc2

[Kees Cook]

On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2019/03/28 4:16, Kees Cook wrote:
> > The part I don't understand is what you've said about TOMOYO being
> > primary and not wanting the others stackable? That kind of goes
> > against the point, but I'm happy to do that if you want it that way.
>
> Automatically enabling multiple legacy major LSMs might result in a confusion like
> Jakub encountered.

The confusion wasn't multiple enabled: it was a change of what was
enabled (due to ignoring the old config). (My very first suggested
patch fixed this...)

> For a few releases from 5.1 (about one year or so?), since
> CONFIG_DEFAULT_SECURITY_* will be ignored after CONFIG_LSM is once defined in
> their kernel configs, I guess that it is better not to enable TOMOYO automatically
> until most people complete migrating from CONFIG_DEFAULT_SECURITY_* to CONFIG_LSM
> and get used to use lsm= kernel command line option rather than security= kernel
> command line option.

It sounds like you want TOMOYO to stay an exclusive LSM? Should we
revert a5e2fe7ede12 ("TOMOYO: Update LSM flags to no longer be
exclusive") instead? (I'm against this idea, but defer to you. I think
it should stay stackable since the goal is to entirely remove the
concept of exclusive LSMs.)

I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
also initializing TOMOYO, though. It should be a no-op. Is there some
situation where this is not true?

The situation you helped me see was that a TOMOYO user with
CONFIG_DEFAULT_SECURITY_TOMOYO would not want to see any exclusive LSM
also initialized, since that may NOT be a no-op.

So, AFAICT, my proposal fixes both Jakub's issue
(CONFIG_DEFAULT_SECURITY_* oldconfig entirely ignored) and Randy's
issue (subset of Jakub's: choosing DAC should mean no legacy major
initializes), and the "TOMOYO user surprised to see an exclusive LSM
also initialized". If you're happy with the proposed change in my
prior email, I'll send it properly to James. If not, what do you see
that needs changing?

Thanks!

-Kees


--
Kees Cook

Re: Linux 5.1-rc2

[Tetsuo Handa]

On 2019/03/28 5:45, Kees Cook wrote:
> On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>
>> On 2019/03/28 4:16, Kees Cook wrote:
>>> The part I don't understand is what you've said about TOMOYO being
>>> primary and not wanting the others stackable? That kind of goes
>>> against the point, but I'm happy to do that if you want it that way.
>>
>> Automatically enabling multiple legacy major LSMs might result in a confusion like
>> Jakub encountered.
> 
> The confusion wasn't multiple enabled: it was a change of what was
> enabled (due to ignoring the old config). (My very first suggested
> patch fixed this...)

Someone else might get confused when TOMOYO is automatically enabled
despite they did not specify TOMOYO in lsm= or security= or CONFIG_LSM.

> 
>> For a few releases from 5.1 (about one year or so?), since
>> CONFIG_DEFAULT_SECURITY_* will be ignored after CONFIG_LSM is once defined in
>> their kernel configs, I guess that it is better not to enable TOMOYO automatically
>> until most people complete migrating from CONFIG_DEFAULT_SECURITY_* to CONFIG_LSM
>> and get used to use lsm= kernel command line option rather than security= kernel
>> command line option.
> 
> It sounds like you want TOMOYO to stay an exclusive LSM? Should we
> revert a5e2fe7ede12 ("TOMOYO: Update LSM flags to no longer be
> exclusive") instead? (I'm against this idea, but defer to you. I think
> it should stay stackable since the goal is to entirely remove the
> concept of exclusive LSMs.)

I never want to revert a5e2fe7ede12. For transition period, I just don't
want to automatically enable TOMOYO when people did not specify TOMOYO.

> 
> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
> also initializing TOMOYO, though. It should be a no-op. Is there some
> situation where this is not true?

There should be no problem except some TOMOYO messages are printed.

Re: Linux 5.1-rc2

[Kees Cook]

On Wed, Mar 27, 2019 at 2:05 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2019/03/28 5:45, Kees Cook wrote:
> > On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >>
> >> On 2019/03/28 4:16, Kees Cook wrote:
> >>> The part I don't understand is what you've said about TOMOYO being
> >>> primary and not wanting the others stackable? That kind of goes
> >>> against the point, but I'm happy to do that if you want it that way.
> >>
> >> Automatically enabling multiple legacy major LSMs might result in a confusion like
> >> Jakub encountered.
> >
> > The confusion wasn't multiple enabled: it was a change of what was
> > enabled (due to ignoring the old config). (My very first suggested
> > patch fixed this...)
>
> Someone else might get confused when TOMOYO is automatically enabled
> despite they did not specify TOMOYO in lsm= or security= or CONFIG_LSM.
>
> >
> >> For a few releases from 5.1 (about one year or so?), since
> >> CONFIG_DEFAULT_SECURITY_* will be ignored after CONFIG_LSM is once defined in
> >> their kernel configs, I guess that it is better not to enable TOMOYO automatically
> >> until most people complete migrating from CONFIG_DEFAULT_SECURITY_* to CONFIG_LSM
> >> and get used to use lsm= kernel command line option rather than security= kernel
> >> command line option.
> >
> > It sounds like you want TOMOYO to stay an exclusive LSM? Should we
> > revert a5e2fe7ede12 ("TOMOYO: Update LSM flags to no longer be
> > exclusive") instead? (I'm against this idea, but defer to you. I think
> > it should stay stackable since the goal is to entirely remove the
> > concept of exclusive LSMs.)
>
> I never want to revert a5e2fe7ede12. For transition period, I just don't
> want to automatically enable TOMOYO when people did not specify TOMOYO.
>
> >
> > I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
> > also initializing TOMOYO, though. It should be a no-op. Is there some
> > situation where this is not true?
>
> There should be no problem except some TOMOYO messages are printed.

Okay, so I should send my latest version of the patch to James? Or do
you explicitly want TOMOYO removed from all the CONFIG_LSM default
lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
the latter will lead to less testing of the stacking.)

-- 
Kees Cook

Re: Linux 5.1-rc2

[Tetsuo Handa]

On 2019/03/28 6:43, Kees Cook wrote:
>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>> situation where this is not true?
>>
>> There should be no problem except some TOMOYO messages are printed.
> 
> Okay, so I should send my latest version of the patch to James? Or do
> you explicitly want TOMOYO removed from all the CONFIG_LSM default
> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
> the latter will lead to less testing of the stacking.)
> 

My approach is "opt-in" while your approach is "opt-out". And the problem
here is that people might fail to change CONFIG_LSM from the default value
to what they need. (And Jakub did not change CONFIG_LSM to reflect
CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest
"opt-in" approach; which includes up to only one legacy major LSM and allows
people to change the default value to include multiple legacy major LSMs.

You can propose your latest version. If SELinux/Smack/AppArmor people
prefer "opt-out" approach, I'm fine with "opt-out" approach.

Re: Linux 5.1-rc2

[Casey Schaufler]

On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
> On 2019/03/28 6:43, Kees Cook wrote:
>>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>>> situation where this is not true?
>>> There should be no problem except some TOMOYO messages are printed.
>> Okay, so I should send my latest version of the patch to James? Or do
>> you explicitly want TOMOYO removed from all the CONFIG_LSM default
>> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
>> the latter will lead to less testing of the stacking.)
>>
> My approach is "opt-in" while your approach is "opt-out". And the problem
> here is that people might fail to change CONFIG_LSM from the default value
> to what they need. (And Jakub did not change CONFIG_LSM to reflect
> CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest
> "opt-in" approach; which includes up to only one legacy major LSM and allows
> people to change the default value to include multiple legacy major LSMs.
>
> You can propose your latest version. If SELinux/Smack/AppArmor people
> prefer "opt-out" approach, I'm fine with "opt-out" approach.

In the long haul we want people to use CONFIG_LSM to set their
list of modules. Providing a backward compatible CONFIG_DEFAULT_SECURITY_BLAH
makes some sense, but it's important that we encourage a mindset change.
Maybe with CONFIG_DEFAULT_SECURITY_LIST with a a full list, which uses the
value from CONFIG_LSM, and make it the default?

Re: Linux 5.1-rc2

[Randy Dunlap]

On 3/27/19 3:23 PM, Casey Schaufler wrote:
> On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
>> On 2019/03/28 6:43, Kees Cook wrote:
>>>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>>>> situation where this is not true?
>>>> There should be no problem except some TOMOYO messages are printed.
>>> Okay, so I should send my latest version of the patch to James? Or do
>>> you explicitly want TOMOYO removed from all the CONFIG_LSM default
>>> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
>>> the latter will lead to less testing of the stacking.)
>>>
>> My approach is "opt-in" while your approach is "opt-out". And the problem
>> here is that people might fail to change CONFIG_LSM from the default value
>> to what they need. (And Jakub did not change CONFIG_LSM to reflect
>> CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest
>> "opt-in" approach; which includes up to only one legacy major LSM and allows
>> people to change the default value to include multiple legacy major LSMs.
>>
>> You can propose your latest version. If SELinux/Smack/AppArmor people
>> prefer "opt-out" approach, I'm fine with "opt-out" approach.
> 
> In the long haul we want people to use CONFIG_LSM to set their
> list of modules. Providing a backward compatible CONFIG_DEFAULT_SECURITY_BLAH
> makes some sense, but it's important that we encourage a mindset change.
> Maybe with CONFIG_DEFAULT_SECURITY_LIST with a a full list, which uses the
> value from CONFIG_LSM, and make it the default?
> 

Hi,

I'm still confused.  Does this mindset change include removing support of
SECURITY_DAC?  If so, where was this discussed and decided?
And if so (again), that feels like enforcing some kind of policy in the kernel.

thanks.
-- 
~Randy

Re: Linux 5.1-rc2

[Casey Schaufler]

On 3/27/2019 3:55 PM, Randy Dunlap wrote:
> On 3/27/19 3:23 PM, Casey Schaufler wrote:
>> On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
>>> On 2019/03/28 6:43, Kees Cook wrote:
>>>>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>>>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>>>>> situation where this is not true?
>>>>> There should be no problem except some TOMOYO messages are printed.
>>>> Okay, so I should send my latest version of the patch to James? Or do
>>>> you explicitly want TOMOYO removed from all the CONFIG_LSM default
>>>> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
>>>> the latter will lead to less testing of the stacking.)
>>>>
>>> My approach is "opt-in" while your approach is "opt-out". And the problem
>>> here is that people might fail to change CONFIG_LSM from the default value
>>> to what they need. (And Jakub did not change CONFIG_LSM to reflect
>>> CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest
>>> "opt-in" approach; which includes up to only one legacy major LSM and allows
>>> people to change the default value to include multiple legacy major LSMs.
>>>
>>> You can propose your latest version. If SELinux/Smack/AppArmor people
>>> prefer "opt-out" approach, I'm fine with "opt-out" approach.
>> In the long haul we want people to use CONFIG_LSM to set their
>> list of modules. Providing a backward compatible CONFIG_DEFAULT_SECURITY_BLAH
>> makes some sense, but it's important that we encourage a mindset change.
>> Maybe with CONFIG_DEFAULT_SECURITY_LIST with a a full list, which uses the
>> value from CONFIG_LSM, and make it the default?
>>
> Hi,
>
> I'm still confused.  Does this mindset change include removing support of
> SECURITY_DAC?

No.

>    If so, where was this discussed and decided?

linux-security-module@vger.kernel.org on threads related to security
module stacking. It's easy to get the same result with a CONFIG_LSM
that includes none of the SELinux, Smack, TOMOYO or AppArmor.

> And if so (again), that feels like enforcing some kind of policy in the kernel.

Again, not so. It's a change from "The not-more-the One Major Module" to
"Whatever set of policies works for you". The NULL set is completely
supported. The current flap is that it's more difficult to express doing
things the old way. Kees and Tetsuo are hashing out how best to support
old .confg files in support of automated tools.


> thanks.

Re: Linux 5.1-rc2

[James Morris]

On Wed, 27 Mar 2019, Kees Cook wrote:

> > There should be no problem except some TOMOYO messages are printed.
> 
> Okay, so I should send my latest version of the patch to James? Or do
> you explicitly want TOMOYO removed from all the CONFIG_LSM default
> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
> the latter will lead to less testing of the stacking.)

Kees, send me your final patch as soon as it's ready.


-- 
James Morris
<jmorris@namei.org>