* 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-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
* 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-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
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).