* Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.
[not found] ` <0d23d1a5-d4af-debf-6b5f-aaaf698daaa8@schaufler-ca.com>
@ 2019-02-07 2:30 ` Tetsuo Handa
2019-02-07 16:24 ` Casey Schaufler
0 siblings, 1 reply; 8+ messages in thread
From: Tetsuo Handa @ 2019-02-07 2:30 UTC (permalink / raw)
To: Casey Schaufler
Cc: Dmitry Vyukov, Paul Moore, Stephen Smalley, syzbot, tyhicks,
John Johansen, James Morris, LKML, linux-security-module,
Serge Hallyn, syzkaller-bugs, Jeffrey Vander Stoep, SELinux,
Russell Coker, Laurent Bigonville, syzkaller, Andrew Morton
Casey Schaufler wrote:
> On 2/6/2019 2:23 AM, Tetsuo Handa wrote:
> > But as I update the documentation ( https://tomoyo.osdn.jp/2.6/chapter-3.html.en#3.6 ),
> > I came to think that we should ignore security= parameter when lsm= parameter is specified.
> >
> > Currently, it is possible to enable TOMOYO and only one of SELinux/Smack/AppArmor. Therefore,
> > it is possible to disable only TOMOYO by specifying security=selinux when we want to enable
> > only SELinux, by specifying security=smack when we want to enable only Smack, by specifying
> > security=apparmor when we want to enable only AppArmor. That is, we can use security= parameter
> > in order to specify the other LSM module which should not be disabled.
> >
> > But when it becomes possible to enable TOMOYO and more than one of SELinux/Smack/AppArmor,
> > we will no longer be able to selectively disable one LSM module using security= parameter, for
> > security= parameter is intended for specifying only one LSM module which should be enabled.
> > That is, we will need to use lsm= parameter in order to selectively disable LSM modules.
>
> Yes. That is correct. The existing behavior of security= is maintained.
But the existing behavior of CONFIG_DEFAULT_SECURITY is not maintained.
This might cause a problem like
commit e5a3b95f581da62e2054ef79d3be2d383e9ed664
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Sat Feb 14 11:46:56 2009 +0900
TOMOYO: Don't create securityfs entries unless registered.
TOMOYO should not create /sys/kernel/security/tomoyo/ interface unless
TOMOYO is registered.
for Ubuntu users because Ubuntu kernels are built with
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SMACK=y
CONFIG_SECURITY_TOMOYO=y
CONFIG_SECURITY_APPARMOR=y
CONFIG_SECURITY_YAMA=y
CONFIG_DEFAULT_SECURITY="apparmor"
. Due to CONFIG_DEFAULT_SECURITY="apparmor", majority of Ubuntu users are enabling
only AppArmor without explicitly specifying "security=apparmor".
Currently default CONFIG_LSM setting is
"yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
but Ubuntu kernels would have to be built with non-default CONFIG_LSM setting like
"yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo"
in order to make sure that AppArmor is by default chosen for the LSM_FLAG_EXCLUSIVE module.
Now that TOMOYO becomes a !LSM_FLAG_EXCLUSIVE module, not specifying "security=apparmor" will
automatically enable TOMOYO. And majority of Ubuntu users will unexpectedly encounter TOMOYO
messages. But removing "tomoyo" from CONFIG_LSM setting in order to save majority of Ubuntu
users from unexpectedly encountering TOMOYO messages also has a problem; Ubuntu users who want
to enable only TOMOYO from LSM_FLAG_LEGACY_MAJOR modules can specify "security=tomoyo", but
Ubuntu users who want to enable TOMOYO and one of SELinux,Smack,AppArmor (including syzbot)
will have to explicitly specify "lsm=" because "security=" can't allow enabling multiple
LSM_FLAG_LEGACY_MAJOR modules.
> The new behavior of lsm= is provided to allow general handling of a list
> of security modules. It uses the same form of data as CONFIG_LSM.
>
> > Then, I think that it is straightforward (and easier to manage) to ignore security= parameter
> > when lsm= parameter is specified.
>
> That reduces flexibility somewhat. If I am debugging security modules
> I may want to use lsm= to specify the order while using security= to
> identify a specific exclusive module. I could do that using lsm= by
> itself, but habits die hard.
"lsm=" can be used for identifying a specific exclusive module, and Ubuntu kernels would
have to use CONFIG_LSM (or "lsm=") for identifying the default exclusive module (in order
to allow enabling both TOMOYO and one of SELinux,Smack,AppArmor at the same time).
Since "security=" can't be used for selectively enable/disable more than one of
SELinux,Smack,TOMOYO,AppArmor, I think that recommending users to migrate to "lsm=" is the
better direction. And ignoring "security=" when "lsm=" is specified is easier to understand.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.
2019-02-07 2:30 ` [PATCH] LSM: Allow syzbot to ignore security= parameter Tetsuo Handa
@ 2019-02-07 16:24 ` Casey Schaufler
2019-02-08 10:52 ` Tetsuo Handa
2019-02-08 21:33 ` Kees Cook
0 siblings, 2 replies; 8+ messages in thread
From: Casey Schaufler @ 2019-02-07 16:24 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Dmitry Vyukov, Paul Moore, Stephen Smalley, syzbot, tyhicks,
John Johansen, James Morris, LKML, linux-security-module,
Serge Hallyn, syzkaller-bugs, Jeffrey Vander Stoep, SELinux,
Russell Coker, Laurent Bigonville, syzkaller, Andrew Morton,
Kees Cook
On 2/6/2019 6:30 PM, Tetsuo Handa wrote:
> Casey Schaufler wrote:
>> On 2/6/2019 2:23 AM, Tetsuo Handa wrote:
>>> But as I update the documentation ( https://tomoyo.osdn.jp/2.6/chapter-3.html.en#3.6 ),
>>> I came to think that we should ignore security= parameter when lsm= parameter is specified.
>>>
>>> Currently, it is possible to enable TOMOYO and only one of SELinux/Smack/AppArmor. Therefore,
>>> it is possible to disable only TOMOYO by specifying security=selinux when we want to enable
>>> only SELinux, by specifying security=smack when we want to enable only Smack, by specifying
>>> security=apparmor when we want to enable only AppArmor. That is, we can use security= parameter
>>> in order to specify the other LSM module which should not be disabled.
>>>
>>> But when it becomes possible to enable TOMOYO and more than one of SELinux/Smack/AppArmor,
>>> we will no longer be able to selectively disable one LSM module using security= parameter, for
>>> security= parameter is intended for specifying only one LSM module which should be enabled.
>>> That is, we will need to use lsm= parameter in order to selectively disable LSM modules.
>> Yes. That is correct. The existing behavior of security= is maintained.
> But the existing behavior of CONFIG_DEFAULT_SECURITY is not maintained.
That's a developer interface, not a user interface. I realize
that may be splitting hairs, but it had to change.
> This might cause a problem like
>
> commit e5a3b95f581da62e2054ef79d3be2d383e9ed664
> Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Sat Feb 14 11:46:56 2009 +0900
>
> TOMOYO: Don't create securityfs entries unless registered.
>
> TOMOYO should not create /sys/kernel/security/tomoyo/ interface unless
> TOMOYO is registered.
>
> for Ubuntu users because Ubuntu kernels are built with
>
> CONFIG_SECURITY_SELINUX=y
> CONFIG_SECURITY_SMACK=y
> CONFIG_SECURITY_TOMOYO=y
> CONFIG_SECURITY_APPARMOR=y
> CONFIG_SECURITY_YAMA=y
> CONFIG_DEFAULT_SECURITY="apparmor"
>
> . Due to CONFIG_DEFAULT_SECURITY="apparmor", majority of Ubuntu users are enabling
> only AppArmor without explicitly specifying "security=apparmor".
>
> Currently default CONFIG_LSM setting is
>
> "yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor"
>
> but Ubuntu kernels would have to be built with non-default CONFIG_LSM setting like
>
> "yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo"
>
> in order to make sure that AppArmor is by default chosen for the LSM_FLAG_EXCLUSIVE module.
Yes, and Yocto Project is likely to want Smack specified first.
> Now that TOMOYO becomes a !LSM_FLAG_EXCLUSIVE module, not specifying "security=apparmor" will
> automatically enable TOMOYO. And majority of Ubuntu users will unexpectedly encounter TOMOYO
> messages. But removing "tomoyo" from CONFIG_LSM setting in order to save majority of Ubuntu
> users from unexpectedly encountering TOMOYO messages also has a problem; Ubuntu users who want
> to enable only TOMOYO from LSM_FLAG_LEGACY_MAJOR modules can specify "security=tomoyo", but
> Ubuntu users who want to enable TOMOYO and one of SELinux,Smack,AppArmor (including syzbot)
> will have to explicitly specify "lsm=" because "security=" can't allow enabling multiple
> LSM_FLAG_LEGACY_MAJOR modules.
I believe we got general buy in from Ubuntu, and I understand
that the LSM list is awkward, but I don't see a rational alternate.
I know that I played with a half dozen, and nothing was closer to
maintaining the status quo.
>> The new behavior of lsm= is provided to allow general handling of a list
>> of security modules. It uses the same form of data as CONFIG_LSM.
>>
>>> Then, I think that it is straightforward (and easier to manage) to ignore security= parameter
>>> when lsm= parameter is specified.
>> That reduces flexibility somewhat. If I am debugging security modules
>> I may want to use lsm= to specify the order while using security= to
>> identify a specific exclusive module. I could do that using lsm= by
>> itself, but habits die hard.
> "lsm=" can be used for identifying a specific exclusive module, and Ubuntu kernels would
> have to use CONFIG_LSM (or "lsm=") for identifying the default exclusive module (in order
> to allow enabling both TOMOYO and one of SELinux,Smack,AppArmor at the same time).
>
> Since "security=" can't be used for selectively enable/disable more than one of
> SELinux,Smack,TOMOYO,AppArmor, I think that recommending users to migrate to "lsm=" is the
> better direction. And ignoring "security=" when "lsm=" is specified is easier to understand.
I added Kees to the CC list. Kees, what to you think about
ignoring security= if lsm= is specified? I'm ambivalent.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.
2019-02-07 16:24 ` Casey Schaufler
@ 2019-02-08 10:52 ` Tetsuo Handa
2019-02-08 16:23 ` Casey Schaufler
2019-02-08 21:49 ` Kees Cook
2019-02-08 21:33 ` Kees Cook
1 sibling, 2 replies; 8+ messages in thread
From: Tetsuo Handa @ 2019-02-08 10:52 UTC (permalink / raw)
To: Casey Schaufler, Kees Cook
Cc: Dmitry Vyukov, Paul Moore, Stephen Smalley, syzbot, tyhicks,
John Johansen, James Morris, LKML, linux-security-module,
Serge Hallyn, syzkaller-bugs, Jeffrey Vander Stoep, SELinux,
Russell Coker, Laurent Bigonville, syzkaller, Andrew Morton
On 2019/02/08 1:24, Casey Schaufler wrote:
>>>> Then, I think that it is straightforward (and easier to manage) to ignore security= parameter
>>>> when lsm= parameter is specified.
>>> That reduces flexibility somewhat. If I am debugging security modules
>>> I may want to use lsm= to specify the order while using security= to
>>> identify a specific exclusive module. I could do that using lsm= by
>>> itself, but habits die hard.
>> "lsm=" can be used for identifying a specific exclusive module, and Ubuntu kernels would
>> have to use CONFIG_LSM (or "lsm=") for identifying the default exclusive module (in order
>> to allow enabling both TOMOYO and one of SELinux,Smack,AppArmor at the same time).
>>
>> Since "security=" can't be used for selectively enable/disable more than one of
>> SELinux,Smack,TOMOYO,AppArmor, I think that recommending users to migrate to "lsm=" is the
>> better direction. And ignoring "security=" when "lsm=" is specified is easier to understand.
>
> I added Kees to the CC list. Kees, what to you think about
> ignoring security= if lsm= is specified? I'm ambivalent.
>
>
To help administrators easily understand what LSM modules are possibly enabled by default (which
have to be fetched from e.g. /boot/config-`uname -r`) and specify lsm= parameter when they need,
I propose changes shown below.
diff --git a/security/security.c b/security/security.c
index 3147785e..051d708 100644
--- a/security/security.c
+++ b/security/security.c
@@ -51,8 +51,6 @@
static __initdata const char *chosen_lsm_order;
static __initdata const char *chosen_major_lsm;
-static __initconst const char * const builtin_lsm_order = CONFIG_LSM;
-
/* Ordered list of LSMs to initialize. */
static __initdata struct lsm_info **ordered_lsms;
static __initdata struct lsm_info *exclusive;
@@ -284,14 +282,22 @@ static void __init ordered_lsm_parse(const char *order, const char *origin)
static void __init ordered_lsm_init(void)
{
struct lsm_info **lsm;
+ const char *order = CONFIG_LSM;
+ const char *origin = "builtin";
ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
GFP_KERNEL);
- if (chosen_lsm_order)
- ordered_lsm_parse(chosen_lsm_order, "cmdline");
- else
- ordered_lsm_parse(builtin_lsm_order, "builtin");
+ if (chosen_lsm_order) {
+ if (chosen_major_lsm) {
+ pr_info("security= is ignored because of lsm=\n");
+ chosen_major_lsm = NULL;
+ }
+ order = chosen_lsm_order;
+ origin = "cmdline";
+ }
+ pr_info("Security Framework initializing: %s\n", order);
+ ordered_lsm_parse(order, origin);
for (lsm = ordered_lsms; *lsm; lsm++)
prepare_lsm(*lsm);
@@ -333,8 +339,6 @@ int __init security_init(void)
int i;
struct hlist_head *list = (struct hlist_head *) &security_hook_heads;
- pr_info("Security Framework initializing\n");
-
for (i = 0; i < sizeof(security_hook_heads) / sizeof(struct hlist_head);
i++)
INIT_HLIST_HEAD(&list[i]);
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.
2019-02-08 10:52 ` Tetsuo Handa
@ 2019-02-08 16:23 ` Casey Schaufler
2019-02-09 0:28 ` Tetsuo Handa
2019-02-08 21:49 ` Kees Cook
1 sibling, 1 reply; 8+ messages in thread
From: Casey Schaufler @ 2019-02-08 16:23 UTC (permalink / raw)
To: Tetsuo Handa, Kees Cook
Cc: Dmitry Vyukov, Paul Moore, Stephen Smalley, syzbot, tyhicks,
John Johansen, James Morris, LKML, linux-security-module,
Serge Hallyn, syzkaller-bugs, Jeffrey Vander Stoep, SELinux,
Russell Coker, Laurent Bigonville, syzkaller, Andrew Morton
On 2/8/2019 2:52 AM, Tetsuo Handa wrote:
> On 2019/02/08 1:24, Casey Schaufler wrote:
>>>>> Then, I think that it is straightforward (and easier to manage) to ignore security= parameter
>>>>> when lsm= parameter is specified.
>>>> That reduces flexibility somewhat. If I am debugging security modules
>>>> I may want to use lsm= to specify the order while using security= to
>>>> identify a specific exclusive module. I could do that using lsm= by
>>>> itself, but habits die hard.
>>> "lsm=" can be used for identifying a specific exclusive module, and Ubuntu kernels would
>>> have to use CONFIG_LSM (or "lsm=") for identifying the default exclusive module (in order
>>> to allow enabling both TOMOYO and one of SELinux,Smack,AppArmor at the same time).
>>>
>>> Since "security=" can't be used for selectively enable/disable more than one of
>>> SELinux,Smack,TOMOYO,AppArmor, I think that recommending users to migrate to "lsm=" is the
>>> better direction. And ignoring "security=" when "lsm=" is specified is easier to understand.
>> I added Kees to the CC list. Kees, what to you think about
>> ignoring security= if lsm= is specified? I'm ambivalent.
>>
>>
> To help administrators easily understand what LSM modules are possibly enabled by default (which
> have to be fetched from e.g. /boot/config-`uname -r`)
$ cat /sys/kernel/security/lsm
> and specify lsm= parameter when they need,
> I propose changes shown below.
>
> diff --git a/security/security.c b/security/security.c
> index 3147785e..051d708 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -51,8 +51,6 @@
> static __initdata const char *chosen_lsm_order;
> static __initdata const char *chosen_major_lsm;
>
> -static __initconst const char * const builtin_lsm_order = CONFIG_LSM;
> -
> /* Ordered list of LSMs to initialize. */
> static __initdata struct lsm_info **ordered_lsms;
> static __initdata struct lsm_info *exclusive;
> @@ -284,14 +282,22 @@ static void __init ordered_lsm_parse(const char *order, const char *origin)
> static void __init ordered_lsm_init(void)
> {
> struct lsm_info **lsm;
> + const char *order = CONFIG_LSM;
> + const char *origin = "builtin";
>
> ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
> GFP_KERNEL);
>
> - if (chosen_lsm_order)
> - ordered_lsm_parse(chosen_lsm_order, "cmdline");
> - else
> - ordered_lsm_parse(builtin_lsm_order, "builtin");
> + if (chosen_lsm_order) {
> + if (chosen_major_lsm) {
> + pr_info("security= is ignored because of lsm=\n");
> + chosen_major_lsm = NULL;
> + }
> + order = chosen_lsm_order;
> + origin = "cmdline";
> + }
> + pr_info("Security Framework initializing: %s\n", order);
> + ordered_lsm_parse(order, origin);
>
> for (lsm = ordered_lsms; *lsm; lsm++)
> prepare_lsm(*lsm);
> @@ -333,8 +339,6 @@ int __init security_init(void)
> int i;
> struct hlist_head *list = (struct hlist_head *) &security_hook_heads;
>
> - pr_info("Security Framework initializing\n");
> -
> for (i = 0; i < sizeof(security_hook_heads) / sizeof(struct hlist_head);
> i++)
> INIT_HLIST_HEAD(&list[i]);
I'm not going to object to this, but I don't see it as important.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.
2019-02-07 16:24 ` Casey Schaufler
2019-02-08 10:52 ` Tetsuo Handa
@ 2019-02-08 21:33 ` Kees Cook
1 sibling, 0 replies; 8+ messages in thread
From: Kees Cook @ 2019-02-08 21:33 UTC (permalink / raw)
To: Casey Schaufler
Cc: Tetsuo Handa, Dmitry Vyukov, Paul Moore, Stephen Smalley, syzbot,
Tyler Hicks, John Johansen, James Morris, LKML,
linux-security-module, Serge Hallyn, syzkaller-bugs,
Jeffrey Vander Stoep, SELinux, Russell Coker, Laurent Bigonville,
syzkaller, Andrew Morton
On Thu, Feb 7, 2019 at 8:24 AM Casey Schaufler <casey@schaufler-ca.com> wrote:
> I added Kees to the CC list. Kees, what to you think about
> ignoring security= if lsm= is specified? I'm ambivalent.
This was one of many earlier suggestions, and the consensus seemed to
be "don't mix security= and lsm=". Why would anyone use both?
--
Kees Cook
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.
2019-02-08 10:52 ` Tetsuo Handa
2019-02-08 16:23 ` Casey Schaufler
@ 2019-02-08 21:49 ` Kees Cook
1 sibling, 0 replies; 8+ messages in thread
From: Kees Cook @ 2019-02-08 21:49 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Casey Schaufler, Dmitry Vyukov, Paul Moore, Stephen Smalley,
syzbot, Tyler Hicks, John Johansen, James Morris, LKML,
linux-security-module, Serge Hallyn, syzkaller-bugs,
Jeffrey Vander Stoep, SELinux, Russell Coker, Laurent Bigonville,
syzkaller, Andrew Morton
On Fri, Feb 8, 2019 at 2:52 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2019/02/08 1:24, Casey Schaufler wrote:
> >>>> Then, I think that it is straightforward (and easier to manage) to ignore security= parameter
> >>>> when lsm= parameter is specified.
> >>> That reduces flexibility somewhat. If I am debugging security modules
> >>> I may want to use lsm= to specify the order while using security= to
> >>> identify a specific exclusive module. I could do that using lsm= by
> >>> itself, but habits die hard.
> >> "lsm=" can be used for identifying a specific exclusive module, and Ubuntu kernels would
> >> have to use CONFIG_LSM (or "lsm=") for identifying the default exclusive module (in order
> >> to allow enabling both TOMOYO and one of SELinux,Smack,AppArmor at the same time).
> >>
> >> Since "security=" can't be used for selectively enable/disable more than one of
> >> SELinux,Smack,TOMOYO,AppArmor, I think that recommending users to migrate to "lsm=" is the
> >> better direction. And ignoring "security=" when "lsm=" is specified is easier to understand.
> >
> > I added Kees to the CC list. Kees, what to you think about
> > ignoring security= if lsm= is specified? I'm ambivalent.
> >
> >
>
> To help administrators easily understand what LSM modules are possibly enabled by default (which
> have to be fetched from e.g. /boot/config-`uname -r`) and specify lsm= parameter when they need,
> I propose changes shown below.
>
> diff --git a/security/security.c b/security/security.c
> index 3147785e..051d708 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -51,8 +51,6 @@
> static __initdata const char *chosen_lsm_order;
> static __initdata const char *chosen_major_lsm;
>
> -static __initconst const char * const builtin_lsm_order = CONFIG_LSM;
> -
> /* Ordered list of LSMs to initialize. */
> static __initdata struct lsm_info **ordered_lsms;
> static __initdata struct lsm_info *exclusive;
> @@ -284,14 +282,22 @@ static void __init ordered_lsm_parse(const char *order, const char *origin)
> static void __init ordered_lsm_init(void)
> {
> struct lsm_info **lsm;
> + const char *order = CONFIG_LSM;
> + const char *origin = "builtin";
>
> ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
> GFP_KERNEL);
>
> - if (chosen_lsm_order)
> - ordered_lsm_parse(chosen_lsm_order, "cmdline");
> - else
> - ordered_lsm_parse(builtin_lsm_order, "builtin");
> + if (chosen_lsm_order) {
> + if (chosen_major_lsm) {
> + pr_info("security= is ignored because of lsm=\n");
This is intended to be the new default way to change the LSM
("lsm=..."), so I'd rather not have this appear every time. Also, it
must continue to interact with the builtin ordering, so if you wanted
this, I think better would be to do:
diff --git a/security/security.c b/security/security.c
index 3147785e20d7..e6153ed54361 100644
--- a/security/security.c
+++ b/security/security.c
@@ -288,9 +288,13 @@ static void __init ordered_lsm_init(void)
ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
GFP_KERNEL);
- if (chosen_lsm_order)
+ if (chosen_lsm_order) {
+ if (chosen_major_lsm) {
+ pr_info("security= is ignored because of lsm=\n");
+ chosen_major_lsm = NULL;
+ }
ordered_lsm_parse(chosen_lsm_order, "cmdline");
- else
+ } else
ordered_lsm_parse(builtin_lsm_order, "builtin");
for (lsm = ordered_lsms; *lsm; lsm++)
> + pr_info("Security Framework initializing: %s\n", order);
> + ordered_lsm_parse(order, origin);
>
> for (lsm = ordered_lsms; *lsm; lsm++)
> prepare_lsm(*lsm);
> @@ -333,8 +339,6 @@ int __init security_init(void)
> int i;
> struct hlist_head *list = (struct hlist_head *) &security_hook_heads;
>
> - pr_info("Security Framework initializing\n");
> -
> for (i = 0; i < sizeof(security_hook_heads) / sizeof(struct hlist_head);
> i++)
> INIT_HLIST_HEAD(&list[i]);
--
Kees Cook
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.
2019-02-08 16:23 ` Casey Schaufler
@ 2019-02-09 0:28 ` Tetsuo Handa
2019-02-09 1:40 ` Tetsuo Handa
0 siblings, 1 reply; 8+ messages in thread
From: Tetsuo Handa @ 2019-02-09 0:28 UTC (permalink / raw)
To: Casey Schaufler, Kees Cook
Cc: Dmitry Vyukov, Paul Moore, Stephen Smalley, syzbot, tyhicks,
John Johansen, James Morris, LKML, linux-security-module,
Serge Hallyn, syzkaller-bugs, Jeffrey Vander Stoep, SELinux,
Russell Coker, Laurent Bigonville, syzkaller, Andrew Morton
On 2019/02/09 1:23, Casey Schaufler wrote:
> On 2/8/2019 2:52 AM, Tetsuo Handa wrote:
>> To help administrators easily understand what LSM modules are possibly enabled by default (which
>> have to be fetched from e.g. /boot/config-`uname -r`)
>
> $ cat /sys/kernel/security/lsm
>
/sys/kernel/security/lsm is list of "actually" enabled modules, isn't it?
What I want is "possibly" enabled modules. Ubuntu would chose from either
(a) explicitly add security=apparmor to kernel command line
or
(b) explicitly remove tomoyo from CONFIG_LSM at kernel config
in order not to enable TOMOYO for those who want to enable only one of
SELinux/Smack/AppArmor. And for those who want to enable TOMOYO, I think
that (b) (in other words, add
lsm="modules listed in CONFIG_LSM" + ",tomoyo"
) will retain compatibility when it becomes possible to enable more than
one of SELinux/Smack/AppArmor at the same time.
If we can know "possibly" enabled modules from dmesg, users don't need to
look at e.g. /boot/config-`uname -r`. It is not essential, but it's handy.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] LSM: Allow syzbot to ignore security= parameter.
2019-02-09 0:28 ` Tetsuo Handa
@ 2019-02-09 1:40 ` Tetsuo Handa
0 siblings, 0 replies; 8+ messages in thread
From: Tetsuo Handa @ 2019-02-09 1:40 UTC (permalink / raw)
To: Casey Schaufler, Kees Cook
Cc: Dmitry Vyukov, Paul Moore, Stephen Smalley, syzbot, tyhicks,
John Johansen, James Morris, LKML, linux-security-module,
Serge Hallyn, syzkaller-bugs, Jeffrey Vander Stoep, SELinux,
Russell Coker, Laurent Bigonville, syzkaller, Andrew Morton
On 2019/02/09 9:28, Tetsuo Handa wrote:
> On 2019/02/09 1:23, Casey Schaufler wrote:
>> On 2/8/2019 2:52 AM, Tetsuo Handa wrote:
>>> To help administrators easily understand what LSM modules are possibly enabled by default (which
>>> have to be fetched from e.g. /boot/config-`uname -r`)
>>
>> $ cat /sys/kernel/security/lsm
>>
>
> /sys/kernel/security/lsm is list of "actually" enabled modules, isn't it?
> What I want is "possibly" enabled modules. Ubuntu would chose from either
>
> (a) explicitly add security=apparmor to kernel command line
>
> or
>
> (b) explicitly remove tomoyo from CONFIG_LSM at kernel config
>
> in order not to enable TOMOYO for those who want to enable only one of
> SELinux/Smack/AppArmor. And for those who want to enable TOMOYO, I think
> that (b) (in other words, add
>
> lsm="modules listed in CONFIG_LSM" + ",tomoyo"
>
> ) will retain compatibility when it becomes possible to enable more than
> one of SELinux/Smack/AppArmor at the same time.
>
> If we can know "possibly" enabled modules from dmesg, users don't need to
> look at e.g. /boot/config-`uname -r`. It is not essential, but it's handy.
>
Well, thinking again, specifying
lsm="modules listed in /sys/kernel/security/lsm" + ",tomoyo"
makes sense, for there is no need to care about disabled modules when
enabling TOMOYO. Therefore,
+ pr_info("Security Framework initializing: %s\n", order);
- pr_info("Security Framework initializing\n");
won't be needed.
On 2019/02/09 6:33, Kees Cook wrote:
> On Thu, Feb 7, 2019 at 8:24 AM Casey Schaufler <casey@schaufler-ca.com> wrote:
>> I added Kees to the CC list. Kees, what to you think about
>> ignoring security= if lsm= is specified? I'm ambivalent.
>
> This was one of many earlier suggestions, and the consensus seemed to
> be "don't mix security= and lsm=". Why would anyone use both?
>
Then, can we add this change?
+ if (chosen_lsm_order) {
+ if (chosen_major_lsm) {
+ pr_info("security= is ignored because of lsm=\n");
+ chosen_major_lsm = NULL;
+ }
+ }
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-02-09 1:40 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <8f48e1d0-c109-f8a9-ea94-9659b16cae49@i-love.sakura.ne.jp>
[not found] ` <0d23d1a5-d4af-debf-6b5f-aaaf698daaa8@schaufler-ca.com>
2019-02-07 2:30 ` [PATCH] LSM: Allow syzbot to ignore security= parameter Tetsuo Handa
2019-02-07 16:24 ` Casey Schaufler
2019-02-08 10:52 ` Tetsuo Handa
2019-02-08 16:23 ` Casey Schaufler
2019-02-09 0:28 ` Tetsuo Handa
2019-02-09 1:40 ` Tetsuo Handa
2019-02-08 21:49 ` Kees Cook
2019-02-08 21:33 ` Kees Cook
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).