| Message ID | 20180920162338.21060-27-keescook@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | LSM: Explict LSM ordering | expand |
On 9/20/2018 9:23 AM, Kees Cook wrote: > This removes CONFIG_DEFAULT_SECURITY in favor of the explicit build-time > ordering offered by CONFIG_LSM_ORDER, and adds all the exclusive LSMs > to the ordered LSM initialization. > > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > security/Kconfig | 39 +-------------------------------------- > security/security.c | 23 +---------------------- > 2 files changed, 2 insertions(+), 60 deletions(-) > > diff --git a/security/Kconfig b/security/Kconfig > index 33c9ac3cb759..a2e365420919 100644 > --- a/security/Kconfig > +++ b/security/Kconfig > @@ -239,46 +239,9 @@ source security/yama/Kconfig > > source security/integrity/Kconfig > > -choice > - prompt "Default security module" > - 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 > - Select the security module that will be used by default if the > - kernel parameter security= is not specified. > - > - 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 DEFAULT_SECURITY > - string > - default "selinux" if DEFAULT_SECURITY_SELINUX > - default "smack" if DEFAULT_SECURITY_SMACK > - default "tomoyo" if DEFAULT_SECURITY_TOMOYO > - default "apparmor" if DEFAULT_SECURITY_APPARMOR > - default "" if DEFAULT_SECURITY_DAC > - > 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" When we have "blob-sharing" how could I compile in tomoyo, but exclude it without a boot line option? When we have full stacking, how could I compile in selinux but exclude it? > help > A comma-separated list of LSMs, in initialization order. > Any LSMs left off this list will be link-order initialized > diff --git a/security/security.c b/security/security.c > index f076fdc6b451..628e62fda5fe 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -130,7 +130,6 @@ static void __init parse_lsm_order(const char *order, const char *origin) > > for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { > if (lsm->order == LSM_ORDER_MUTABLE && > - (lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0 && > strcmp(lsm->name, name) == 0) { > append_ordered_lsm(lsm, origin); > found = true; > @@ -163,8 +162,7 @@ static void __init prepare_lsm_order(void) > > /* Add any missing LSMs, in link order. */ > for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { > - if (lsm->order == LSM_ORDER_MUTABLE && > - (lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0) > + if (lsm->order == LSM_ORDER_MUTABLE) > append_ordered_lsm(lsm, "link-time"); > } > > @@ -222,18 +220,6 @@ static void __init ordered_lsm_init(void) > maybe_initialize_lsm(*lsm); > } > > -static void __init major_lsm_init(void) > -{ > - struct lsm_info *lsm; > - > - for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { > - if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0) > - continue; > - > - maybe_initialize_lsm(lsm); > - } > -} > - > /** > * security_init - initializes the security framework > * > @@ -253,8 +239,6 @@ int __init security_init(void) > GFP_KERNEL); > > /* Process "security=", if given. */ > - if (!chosen_major_lsm) > - chosen_major_lsm = CONFIG_DEFAULT_SECURITY; > if (chosen_major_lsm) { > struct lsm_info *lsm; > > @@ -275,11 +259,6 @@ int __init security_init(void) > prepare_lsm_order(); > ordered_lsm_init(); > > - /* > - * Load all the remaining security modules. > - */ > - major_lsm_init(); > - > kfree(ordered_lsms); > return 0; > }
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. > 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. > When we have full stacking, how could I compile in selinux > but exclude it? Yup, same problem. Same suggested solution? Should lsm.enable/disable= also become a comma-separated list, or should I leave it as a multi-instance thing like I have it? -Kees
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. > >> 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 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. >> When we have full stacking, how could I compile in selinux >> but exclude it? > Yup, same problem. Same suggested solution? > > Should lsm.enable/disable= also become a comma-separated list, or > should I leave it as a multi-instance thing like I have it? I prefer the multi-instance lsm.disable=selinux lsm.disable=yama to the list lsm.disable=selinux,yama but at this point I don't really care all that much.
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 >> >>> 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. > >>> When we have full stacking, how could I compile in selinux >>> but exclude it? >> Yup, same problem. Same suggested solution? >> >> Should lsm.enable/disable= also become a comma-separated list, or >> should I leave it as a multi-instance thing like I have it? > > I prefer the multi-instance > lsm.disable=selinux lsm.disable=yama > to the list > lsm.disable=selinux,yama > > but at this point I don't really care all that much. > the comma separated list however is consistent with what is being done for default order
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. >>>> 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? >>>> When we have full stacking, how could I compile in selinux >>>> but exclude it? >>> Yup, same problem. Same suggested solution? >>> >>> Should lsm.enable/disable= also become a comma-separated list, or >>> should I leave it as a multi-instance thing like I have it? >> >> I prefer the multi-instance >> lsm.disable=selinux lsm.disable=yama >> to the list >> lsm.disable=selinux,yama >> >> but at this point I don't really care all that much. > > the comma separated list however is consistent with what is being > done for default order Yeah, and it would match the new CONFIG_LSM_ENABLE. FWIW, it was tedious to type "lsm.enable" and "lsm.disable" over and over when doing testing, so I almost prefer the comma separated list at the end of the day. I'll ponder this a bit. -Kees
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. > >>>>> 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 > >>>>> When we have full stacking, how could I compile in selinux >>>>> but exclude it? >>>> Yup, same problem. Same suggested solution? >>>> >>>> Should lsm.enable/disable= also become a comma-separated list, or >>>> should I leave it as a multi-instance thing like I have it? >>> >>> I prefer the multi-instance >>> lsm.disable=selinux lsm.disable=yama >>> to the list >>> lsm.disable=selinux,yama >>> >>> but at this point I don't really care all that much. >> >> the comma separated list however is consistent with what is being >> done for default order > > Yeah, and it would match the new CONFIG_LSM_ENABLE. > > FWIW, it was tedious to type "lsm.enable" and "lsm.disable" over and > over when doing testing, so I almost prefer the comma separated list > at the end of the day. I'll ponder this a bit. > > -Kees >
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
On 09/20/2018 08:02 PM, Kees Cook wrote: > 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. > me too, I was just trying to throw out options.
On 9/21/2018 6:19 AM, John Johansen wrote: > On 09/20/2018 08:02 PM, Kees Cook wrote: >> 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: >>>> >>>> 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. >> > me too, I was just trying to throw out options. I'll buy that. "all" is fine by me, although it means we can't have an LSM named "all". :) We should also allow "none" to mean no LSMs. I know lots of people who love using security=none.
diff --git a/security/Kconfig b/security/Kconfig index 33c9ac3cb759..a2e365420919 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -239,46 +239,9 @@ source security/yama/Kconfig source security/integrity/Kconfig -choice - prompt "Default security module" - 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 - Select the security module that will be used by default if the - kernel parameter security= is not specified. - - 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 DEFAULT_SECURITY - string - default "selinux" if DEFAULT_SECURITY_SELINUX - default "smack" if DEFAULT_SECURITY_SMACK - default "tomoyo" if DEFAULT_SECURITY_TOMOYO - default "apparmor" if DEFAULT_SECURITY_APPARMOR - default "" if DEFAULT_SECURITY_DAC - config LSM_ORDER string "Default initialization order of builtin LSMs" - default "yama,loadpin,integrity" + default "yama,loadpin,integrity,selinux,smack,tomoyo,apparmor" help A comma-separated list of LSMs, in initialization order. Any LSMs left off this list will be link-order initialized diff --git a/security/security.c b/security/security.c index f076fdc6b451..628e62fda5fe 100644 --- a/security/security.c +++ b/security/security.c @@ -130,7 +130,6 @@ static void __init parse_lsm_order(const char *order, const char *origin) for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { if (lsm->order == LSM_ORDER_MUTABLE && - (lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0 && strcmp(lsm->name, name) == 0) { append_ordered_lsm(lsm, origin); found = true; @@ -163,8 +162,7 @@ static void __init prepare_lsm_order(void) /* Add any missing LSMs, in link order. */ for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { - if (lsm->order == LSM_ORDER_MUTABLE && - (lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0) + if (lsm->order == LSM_ORDER_MUTABLE) append_ordered_lsm(lsm, "link-time"); } @@ -222,18 +220,6 @@ static void __init ordered_lsm_init(void) maybe_initialize_lsm(*lsm); } -static void __init major_lsm_init(void) -{ - struct lsm_info *lsm; - - for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) { - if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0) - continue; - - maybe_initialize_lsm(lsm); - } -} - /** * security_init - initializes the security framework * @@ -253,8 +239,6 @@ int __init security_init(void) GFP_KERNEL); /* Process "security=", if given. */ - if (!chosen_major_lsm) - chosen_major_lsm = CONFIG_DEFAULT_SECURITY; if (chosen_major_lsm) { struct lsm_info *lsm; @@ -275,11 +259,6 @@ int __init security_init(void) prepare_lsm_order(); ordered_lsm_init(); - /* - * Load all the remaining security modules. - */ - major_lsm_init(); - kfree(ordered_lsms); return 0; }
This removes CONFIG_DEFAULT_SECURITY in favor of the explicit build-time ordering offered by CONFIG_LSM_ORDER, and adds all the exclusive LSMs to the ordered LSM initialization. Signed-off-by: Kees Cook <keescook@chromium.org> --- security/Kconfig | 39 +-------------------------------------- security/security.c | 23 +---------------------- 2 files changed, 2 insertions(+), 60 deletions(-)