linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH security-next v4 00/32] LSM: Explict LSM ordering
@ 2018-10-02  0:54 Kees Cook
  2018-10-02  0:54 ` Kees Cook
                   ` (32 more replies)
  0 siblings, 33 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

v4:
- add Reviewed-bys.
- cosmetic tweaks.
- New patches to fully centralize LSM "enable" decisions:
    LSM: Finalize centralized LSM enabling logic
    apparmor: Remove boot parameter
    selinux: Remove boot parameter

v3:
- add CONFIG_LSM_ENABLE and refactor resulting logic

v2:
- add "lsm.order=" and CONFIG_LSM_ORDER instead of overloading "security="
- reorganize introduction of ordering logic code

Overview:

This refactors the LSM registration and initialization infrastructure to
more centrally support different LSM types for more cleanly supporting the
future expansion of LSM stacking via the "blob-sharing" patch series. What
was considered a "major" LSM is kept for legacy use of the "security="
boot parameter, and now overlaps with the new class of "exclusive" LSMs
for the future blob sharing. The "minor" LSMs become more well defined
as a result of the refactoring.

Approach:

To better show LSMs activation some debug reporting was added (enabled
with the "lsm.debug" boot commandline option).

I added a WARN() around LSM initialization failures, which appear to
have always been silently ignored. (Realistically any LSM init failures
would have only been due to catastrophic kernel issues that would render
a system unworkable anyway, but it'd be better to expose the problem as
early as possible.)

Instead of continuing to (somewhat improperly) overload the kernel's
initcall system, this changes the LSM infrastructure to store a
registration structure (struct lsm_info) table instead, where metadata
about each LSM can be recorded (name, flags, order, enable flag, init
function). This can be extended in the future to include things like
required blob size for the coming "blob sharing" LSMs.

The "major" LSMs had to individually negotiate which of them should be
enabled. This didn't provide a way to negotiate combinations of other
LSMs (as will be needed for "blob sharing" LSMs). This is solved by
providing the LSM infrastructure with all the details needed to make
the choice (exposing the per-LSM "enabled" flag, if used, the LSM
characteristics, and ordering expectations).

As a result of the refactoring, the "minor" LSMs are able to remove
the open-coded security_add_hooks() calls for "capability", "yama",
and "loadpin", and to redefine "integrity" properly as a general LSM.
(Note that "integrity" actually defined _no_ hooks, but needs the early
initialization).

With all LSMs being proessed centrally, it was possible to implement
a new boot parameter "lsm.order=" to provide explicit ordering, which
is helpful for the future "blob sharing" LSMs. Matching this is the
new CONFIG_LSM_ORDER, which replaces CONFIG_DEFAULT_SECURITY, as it
provides a higher granularity of control.

Breakdown of patches:

Infrastructure improvements (no logical changes):
  LSM: Correctly announce start of LSM initialization
  vmlinux.lds.h: Avoid copy/paste of security_init section
  LSM: Rename .security_initcall section to .lsm_info
  LSM: Remove initcall tracing
  LSM: Convert from initcall to struct lsm_info
  vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
  LSM: Convert security_initcall() into DEFINE_LSM()
  LSM: Record LSM name in struct lsm_info
  LSM: Provide init debugging infrastructure
  LSM: Don't ignore initialization failures

Split "integrity" out into "ordered initialization" (no logical changes):
  LSM: Introduce LSM_FLAG_LEGACY_MAJOR
  LSM: Provide separate ordered initialization

Provide centralized LSM enable/disable infrastructure:
  LoadPin: Rename "enable" to "enforce"
  LSM: Plumb visibility into optional "enabled" state
  LSM: Lift LSM selection out of individual LSMs
  LSM: Prepare for arbitrary LSM enabling
  LSM: Introduce CONFIG_LSM_ENABLE
  LSM: Introduce lsm.enable= and lsm.disable=
  LSM: Prepare for reorganizing "security=" logic
  LSM: Refactor "security=" in terms of enable/disable
  LSM: Finalize centralized LSM enabling logic
  apparmor: Remove boot parameter
  selinux: Remove boot parameter

Provide centralized LSM ordering infrastructure:
  LSM: Build ordered list of ordered LSMs for init
  LSM: Introduce CONFIG_LSM_ORDER
  LSM: Introduce "lsm.order=" for boottime ordering

Move minor LSMs into ordered LSM initialization:
  LoadPin: Initialize as ordered LSM
  Yama: Initialize as ordered LSM
  LSM: Introduce enum lsm_order
  capability: Initialize as LSM_ORDER_FIRST

Move major LSMs into ordered LSM initialization:
  LSM: Separate idea of "major" LSM from "exclusive" LSM
  LSM: Add all exclusive LSMs to ordered initialization

-Kees

 .../admin-guide/kernel-parameters.txt         |  34 +-
 arch/arc/kernel/vmlinux.lds.S                 |   1 -
 arch/arm/kernel/vmlinux-xip.lds.S             |   1 -
 arch/arm64/kernel/vmlinux.lds.S               |   1 -
 arch/h8300/kernel/vmlinux.lds.S               |   1 -
 arch/microblaze/kernel/vmlinux.lds.S          |   2 -
 arch/powerpc/kernel/vmlinux.lds.S             |   2 -
 arch/um/include/asm/common.lds.S              |   2 -
 arch/xtensa/kernel/vmlinux.lds.S              |   1 -
 include/asm-generic/vmlinux.lds.h             |  25 +-
 include/linux/init.h                          |   2 -
 include/linux/lsm_hooks.h                     |  37 +-
 include/linux/module.h                        |   1 -
 security/Kconfig                              |  61 ++--
 security/apparmor/Kconfig                     |  16 -
 security/apparmor/lsm.c                       |  22 +-
 security/commoncap.c                          |   9 +-
 security/integrity/iint.c                     |   6 +-
 security/loadpin/Kconfig                      |   4 +-
 security/loadpin/loadpin.c                    |  29 +-
 security/security.c                           | 343 +++++++++++++++---
 security/selinux/Kconfig                      |  29 --
 security/selinux/hooks.c                      |  32 +-
 security/smack/smack_lsm.c                    |   9 +-
 security/tomoyo/tomoyo.c                      |   8 +-
 security/yama/yama_lsm.c                      |   8 +-
 26 files changed, 432 insertions(+), 254 deletions(-)

-- 
2.17.1

^ permalink raw reply	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 00/32] LSM: Explict LSM ordering
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 01/32] LSM: Correctly announce start of LSM initialization Kees Cook
                   ` (31 subsequent siblings)
  32 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

v4:
- add Reviewed-bys.
- cosmetic tweaks.
- New patches to fully centralize LSM "enable" decisions:
    LSM: Finalize centralized LSM enabling logic
    apparmor: Remove boot parameter
    selinux: Remove boot parameter

v3:
- add CONFIG_LSM_ENABLE and refactor resulting logic

v2:
- add "lsm.order=" and CONFIG_LSM_ORDER instead of overloading "security="
- reorganize introduction of ordering logic code

Overview:

This refactors the LSM registration and initialization infrastructure to
more centrally support different LSM types for more cleanly supporting the
future expansion of LSM stacking via the "blob-sharing" patch series. What
was considered a "major" LSM is kept for legacy use of the "security="
boot parameter, and now overlaps with the new class of "exclusive" LSMs
for the future blob sharing. The "minor" LSMs become more well defined
as a result of the refactoring.

Approach:

To better show LSMs activation some debug reporting was added (enabled
with the "lsm.debug" boot commandline option).

I added a WARN() around LSM initialization failures, which appear to
have always been silently ignored. (Realistically any LSM init failures
would have only been due to catastrophic kernel issues that would render
a system unworkable anyway, but it'd be better to expose the problem as
early as possible.)

Instead of continuing to (somewhat improperly) overload the kernel's
initcall system, this changes the LSM infrastructure to store a
registration structure (struct lsm_info) table instead, where metadata
about each LSM can be recorded (name, flags, order, enable flag, init
function). This can be extended in the future to include things like
required blob size for the coming "blob sharing" LSMs.

The "major" LSMs had to individually negotiate which of them should be
enabled. This didn't provide a way to negotiate combinations of other
LSMs (as will be needed for "blob sharing" LSMs). This is solved by
providing the LSM infrastructure with all the details needed to make
the choice (exposing the per-LSM "enabled" flag, if used, the LSM
characteristics, and ordering expectations).

As a result of the refactoring, the "minor" LSMs are able to remove
the open-coded security_add_hooks() calls for "capability", "yama",
and "loadpin", and to redefine "integrity" properly as a general LSM.
(Note that "integrity" actually defined _no_ hooks, but needs the early
initialization).

With all LSMs being proessed centrally, it was possible to implement
a new boot parameter "lsm.order=" to provide explicit ordering, which
is helpful for the future "blob sharing" LSMs. Matching this is the
new CONFIG_LSM_ORDER, which replaces CONFIG_DEFAULT_SECURITY, as it
provides a higher granularity of control.

Breakdown of patches:

Infrastructure improvements (no logical changes):
  LSM: Correctly announce start of LSM initialization
  vmlinux.lds.h: Avoid copy/paste of security_init section
  LSM: Rename .security_initcall section to .lsm_info
  LSM: Remove initcall tracing
  LSM: Convert from initcall to struct lsm_info
  vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
  LSM: Convert security_initcall() into DEFINE_LSM()
  LSM: Record LSM name in struct lsm_info
  LSM: Provide init debugging infrastructure
  LSM: Don't ignore initialization failures

Split "integrity" out into "ordered initialization" (no logical changes):
  LSM: Introduce LSM_FLAG_LEGACY_MAJOR
  LSM: Provide separate ordered initialization

Provide centralized LSM enable/disable infrastructure:
  LoadPin: Rename "enable" to "enforce"
  LSM: Plumb visibility into optional "enabled" state
  LSM: Lift LSM selection out of individual LSMs
  LSM: Prepare for arbitrary LSM enabling
  LSM: Introduce CONFIG_LSM_ENABLE
  LSM: Introduce lsm.enable= and lsm.disable=
  LSM: Prepare for reorganizing "security=" logic
  LSM: Refactor "security=" in terms of enable/disable
  LSM: Finalize centralized LSM enabling logic
  apparmor: Remove boot parameter
  selinux: Remove boot parameter

Provide centralized LSM ordering infrastructure:
  LSM: Build ordered list of ordered LSMs for init
  LSM: Introduce CONFIG_LSM_ORDER
  LSM: Introduce "lsm.order=" for boottime ordering

Move minor LSMs into ordered LSM initialization:
  LoadPin: Initialize as ordered LSM
  Yama: Initialize as ordered LSM
  LSM: Introduce enum lsm_order
  capability: Initialize as LSM_ORDER_FIRST

Move major LSMs into ordered LSM initialization:
  LSM: Separate idea of "major" LSM from "exclusive" LSM
  LSM: Add all exclusive LSMs to ordered initialization

-Kees

 .../admin-guide/kernel-parameters.txt         |  34 +-
 arch/arc/kernel/vmlinux.lds.S                 |   1 -
 arch/arm/kernel/vmlinux-xip.lds.S             |   1 -
 arch/arm64/kernel/vmlinux.lds.S               |   1 -
 arch/h8300/kernel/vmlinux.lds.S               |   1 -
 arch/microblaze/kernel/vmlinux.lds.S          |   2 -
 arch/powerpc/kernel/vmlinux.lds.S             |   2 -
 arch/um/include/asm/common.lds.S              |   2 -
 arch/xtensa/kernel/vmlinux.lds.S              |   1 -
 include/asm-generic/vmlinux.lds.h             |  25 +-
 include/linux/init.h                          |   2 -
 include/linux/lsm_hooks.h                     |  37 +-
 include/linux/module.h                        |   1 -
 security/Kconfig                              |  61 ++--
 security/apparmor/Kconfig                     |  16 -
 security/apparmor/lsm.c                       |  22 +-
 security/commoncap.c                          |   9 +-
 security/integrity/iint.c                     |   6 +-
 security/loadpin/Kconfig                      |   4 +-
 security/loadpin/loadpin.c                    |  29 +-
 security/security.c                           | 343 +++++++++++++++---
 security/selinux/Kconfig                      |  29 --
 security/selinux/hooks.c                      |  32 +-
 security/smack/smack_lsm.c                    |   9 +-
 security/tomoyo/tomoyo.c                      |   8 +-
 security/yama/yama_lsm.c                      |   8 +-
 26 files changed, 432 insertions(+), 254 deletions(-)

-- 
2.17.1

^ permalink raw reply	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 01/32] LSM: Correctly announce start of LSM initialization
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
  2018-10-02  0:54 ` Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 02/32] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
                   ` (30 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

For a while now, the LSM core has said it was "initializED", rather than
"initializING". This adjust the report to be more accurate (i.e. before
this was reported before any LSMs had been initialized.)

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/security.c b/security/security.c
index 736e78da1ab9..4cbcf244a965 100644
--- a/security/security.c
+++ b/security/security.c
@@ -72,10 +72,11 @@ 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]);
-	pr_info("Security Framework initialized\n");
 
 	/*
 	 * Load minor LSMs, with the capability module always first.
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 01/32] LSM: Correctly announce start of LSM initialization
  2018-10-02  0:54 ` [PATCH security-next v4 01/32] LSM: Correctly announce start of LSM initialization Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

For a while now, the LSM core has said it was "initializED", rather than
"initializING". This adjust the report to be more accurate (i.e. before
this was reported before any LSMs had been initialized.)

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/security.c b/security/security.c
index 736e78da1ab9..4cbcf244a965 100644
--- a/security/security.c
+++ b/security/security.c
@@ -72,10 +72,11 @@ 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]);
-	pr_info("Security Framework initialized\n");
 
 	/*
 	 * Load minor LSMs, with the capability module always first.
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 02/32] vmlinux.lds.h: Avoid copy/paste of security_init section
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
  2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 01/32] LSM: Correctly announce start of LSM initialization Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 03/32] LSM: Rename .security_initcall section to .lsm_info Kees Cook
                   ` (29 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Avoid copy/paste by defining SECURITY_INIT in terms of SECURITY_INITCALL.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/asm-generic/vmlinux.lds.h | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 7b75ff6e2fce..934a45395547 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -473,13 +473,6 @@
 #define RODATA          RO_DATA_SECTION(4096)
 #define RO_DATA(align)  RO_DATA_SECTION(align)
 
-#define SECURITY_INIT							\
-	.security_initcall.init : AT(ADDR(.security_initcall.init) - LOAD_OFFSET) { \
-		__security_initcall_start = .;				\
-		KEEP(*(.security_initcall.init))			\
-		__security_initcall_end = .;				\
-	}
-
 /*
  * .text section. Map to function alignment to avoid address changes
  * during second ld run in second ld pass when generating System.map
@@ -798,6 +791,12 @@
 		KEEP(*(.security_initcall.init))			\
 		__security_initcall_end = .;
 
+/* Older linker script style for security init. */
+#define SECURITY_INIT							\
+	.security_initcall.init : AT(ADDR(.security_initcall.init) - LOAD_OFFSET) { \
+		SECURITY_INITCALL					\
+	}
+
 #ifdef CONFIG_BLK_DEV_INITRD
 #define INIT_RAM_FS							\
 	. = ALIGN(4);							\
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 02/32] vmlinux.lds.h: Avoid copy/paste of security_init section
  2018-10-02  0:54 ` [PATCH security-next v4 02/32] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Avoid copy/paste by defining SECURITY_INIT in terms of SECURITY_INITCALL.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/asm-generic/vmlinux.lds.h | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 7b75ff6e2fce..934a45395547 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -473,13 +473,6 @@
 #define RODATA          RO_DATA_SECTION(4096)
 #define RO_DATA(align)  RO_DATA_SECTION(align)
 
-#define SECURITY_INIT							\
-	.security_initcall.init : AT(ADDR(.security_initcall.init) - LOAD_OFFSET) { \
-		__security_initcall_start = .;				\
-		KEEP(*(.security_initcall.init))			\
-		__security_initcall_end = .;				\
-	}
-
 /*
  * .text section. Map to function alignment to avoid address changes
  * during second ld run in second ld pass when generating System.map
@@ -798,6 +791,12 @@
 		KEEP(*(.security_initcall.init))			\
 		__security_initcall_end = .;
 
+/* Older linker script style for security init. */
+#define SECURITY_INIT							\
+	.security_initcall.init : AT(ADDR(.security_initcall.init) - LOAD_OFFSET) { \
+		SECURITY_INITCALL					\
+	}
+
 #ifdef CONFIG_BLK_DEV_INITRD
 #define INIT_RAM_FS							\
 	. = ALIGN(4);							\
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 03/32] LSM: Rename .security_initcall section to .lsm_info
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (2 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 02/32] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 04/32] LSM: Remove initcall tracing Kees Cook
                   ` (28 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for switching from initcall to just a regular set of
pointers in a section, rename the internal section name.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/asm-generic/vmlinux.lds.h | 10 +++++-----
 include/linux/init.h              |  4 ++--
 security/security.c               |  4 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 934a45395547..5079a969e612 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -787,14 +787,14 @@
 		__con_initcall_end = .;
 
 #define SECURITY_INITCALL						\
-		__security_initcall_start = .;				\
-		KEEP(*(.security_initcall.init))			\
-		__security_initcall_end = .;
+		__start_lsm_info = .;					\
+		KEEP(*(.lsm_info.init))					\
+		__end_lsm_info = .;
 
 /* Older linker script style for security init. */
 #define SECURITY_INIT							\
-	.security_initcall.init : AT(ADDR(.security_initcall.init) - LOAD_OFFSET) { \
-		SECURITY_INITCALL					\
+	.lsm_info.init : AT(ADDR(.lsm_info.init) - LOAD_OFFSET) {	\
+		LSM_INFO						\
 	}
 
 #ifdef CONFIG_BLK_DEV_INITRD
diff --git a/include/linux/init.h b/include/linux/init.h
index 2538d176dd1f..77636539e77c 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -133,7 +133,7 @@ static inline initcall_t initcall_from_entry(initcall_entry_t *entry)
 #endif
 
 extern initcall_entry_t __con_initcall_start[], __con_initcall_end[];
-extern initcall_entry_t __security_initcall_start[], __security_initcall_end[];
+extern initcall_entry_t __start_lsm_info[], __end_lsm_info[];
 
 /* Used for contructor calls. */
 typedef void (*ctor_fn_t)(void);
@@ -236,7 +236,7 @@ extern bool initcall_debug;
 	static exitcall_t __exitcall_##fn __exit_call = fn
 
 #define console_initcall(fn)	___define_initcall(fn,, .con_initcall)
-#define security_initcall(fn)	___define_initcall(fn,, .security_initcall)
+#define security_initcall(fn)	___define_initcall(fn,, .lsm_info)
 
 struct obs_kernel_param {
 	const char *str;
diff --git a/security/security.c b/security/security.c
index 4cbcf244a965..892fe6b691cf 100644
--- a/security/security.c
+++ b/security/security.c
@@ -51,9 +51,9 @@ static void __init do_security_initcalls(void)
 	initcall_t call;
 	initcall_entry_t *ce;
 
-	ce = __security_initcall_start;
+	ce = __start_lsm_info;
 	trace_initcall_level("security");
-	while (ce < __security_initcall_end) {
+	while (ce < __end_lsm_info) {
 		call = initcall_from_entry(ce);
 		trace_initcall_start(call);
 		ret = call();
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 03/32] LSM: Rename .security_initcall section to .lsm_info
  2018-10-02  0:54 ` [PATCH security-next v4 03/32] LSM: Rename .security_initcall section to .lsm_info Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for switching from initcall to just a regular set of
pointers in a section, rename the internal section name.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/asm-generic/vmlinux.lds.h | 10 +++++-----
 include/linux/init.h              |  4 ++--
 security/security.c               |  4 ++--
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 934a45395547..5079a969e612 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -787,14 +787,14 @@
 		__con_initcall_end = .;
 
 #define SECURITY_INITCALL						\
-		__security_initcall_start = .;				\
-		KEEP(*(.security_initcall.init))			\
-		__security_initcall_end = .;
+		__start_lsm_info = .;					\
+		KEEP(*(.lsm_info.init))					\
+		__end_lsm_info = .;
 
 /* Older linker script style for security init. */
 #define SECURITY_INIT							\
-	.security_initcall.init : AT(ADDR(.security_initcall.init) - LOAD_OFFSET) { \
-		SECURITY_INITCALL					\
+	.lsm_info.init : AT(ADDR(.lsm_info.init) - LOAD_OFFSET) {	\
+		LSM_INFO						\
 	}
 
 #ifdef CONFIG_BLK_DEV_INITRD
diff --git a/include/linux/init.h b/include/linux/init.h
index 2538d176dd1f..77636539e77c 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -133,7 +133,7 @@ static inline initcall_t initcall_from_entry(initcall_entry_t *entry)
 #endif
 
 extern initcall_entry_t __con_initcall_start[], __con_initcall_end[];
-extern initcall_entry_t __security_initcall_start[], __security_initcall_end[];
+extern initcall_entry_t __start_lsm_info[], __end_lsm_info[];
 
 /* Used for contructor calls. */
 typedef void (*ctor_fn_t)(void);
@@ -236,7 +236,7 @@ extern bool initcall_debug;
 	static exitcall_t __exitcall_##fn __exit_call = fn
 
 #define console_initcall(fn)	___define_initcall(fn,, .con_initcall)
-#define security_initcall(fn)	___define_initcall(fn,, .security_initcall)
+#define security_initcall(fn)	___define_initcall(fn,, .lsm_info)
 
 struct obs_kernel_param {
 	const char *str;
diff --git a/security/security.c b/security/security.c
index 4cbcf244a965..892fe6b691cf 100644
--- a/security/security.c
+++ b/security/security.c
@@ -51,9 +51,9 @@ static void __init do_security_initcalls(void)
 	initcall_t call;
 	initcall_entry_t *ce;
 
-	ce = __security_initcall_start;
+	ce = __start_lsm_info;
 	trace_initcall_level("security");
-	while (ce < __security_initcall_end) {
+	while (ce < __end_lsm_info) {
 		call = initcall_from_entry(ce);
 		trace_initcall_start(call);
 		ret = call();
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 04/32] LSM: Remove initcall tracing
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (3 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 03/32] LSM: Rename .security_initcall section to .lsm_info Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:14   ` James Morris
  2018-10-02  0:54 ` [PATCH security-next v4 05/32] LSM: Convert from initcall to struct lsm_info Kees Cook
                   ` (27 subsequent siblings)
  32 siblings, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This partially reverts commit 58eacfffc417 ("init, tracing: instrument
security and console initcall trace events") since security init calls
are about to no longer resemble regular init calls.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/security.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/security/security.c b/security/security.c
index 892fe6b691cf..41a5da2c7faf 100644
--- a/security/security.c
+++ b/security/security.c
@@ -30,8 +30,6 @@
 #include <linux/string.h>
 #include <net/flow.h>
 
-#include <trace/events/initcall.h>
-
 #define MAX_LSM_EVM_XATTR	2
 
 /* Maximum number of letters for an LSM name string */
@@ -47,17 +45,13 @@ static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 
 static void __init do_security_initcalls(void)
 {
-	int ret;
 	initcall_t call;
 	initcall_entry_t *ce;
 
 	ce = __start_lsm_info;
-	trace_initcall_level("security");
 	while (ce < __end_lsm_info) {
 		call = initcall_from_entry(ce);
-		trace_initcall_start(call);
-		ret = call();
-		trace_initcall_finish(call, ret);
+		call();
 		ce++;
 	}
 }
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 04/32] LSM: Remove initcall tracing
  2018-10-02  0:54 ` [PATCH security-next v4 04/32] LSM: Remove initcall tracing Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:14   ` James Morris
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This partially reverts commit 58eacfffc417 ("init, tracing: instrument
security and console initcall trace events") since security init calls
are about to no longer resemble regular init calls.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/security.c | 8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/security/security.c b/security/security.c
index 892fe6b691cf..41a5da2c7faf 100644
--- a/security/security.c
+++ b/security/security.c
@@ -30,8 +30,6 @@
 #include <linux/string.h>
 #include <net/flow.h>
 
-#include <trace/events/initcall.h>
-
 #define MAX_LSM_EVM_XATTR	2
 
 /* Maximum number of letters for an LSM name string */
@@ -47,17 +45,13 @@ static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 
 static void __init do_security_initcalls(void)
 {
-	int ret;
 	initcall_t call;
 	initcall_entry_t *ce;
 
 	ce = __start_lsm_info;
-	trace_initcall_level("security");
 	while (ce < __end_lsm_info) {
 		call = initcall_from_entry(ce);
-		trace_initcall_start(call);
-		ret = call();
-		trace_initcall_finish(call, ret);
+		call();
 		ce++;
 	}
 }
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 05/32] LSM: Convert from initcall to struct lsm_info
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (4 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 04/32] LSM: Remove initcall tracing Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 06/32] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
                   ` (26 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for doing more interesting LSM init probing, this converts
the existing initcall system into an explicit call into a function pointer
from a section-collected struct lsm_info array.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/linux/init.h      |  2 --
 include/linux/lsm_hooks.h | 12 ++++++++++++
 include/linux/module.h    |  1 -
 security/integrity/iint.c |  1 +
 security/security.c       | 14 +++++---------
 5 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index 77636539e77c..9c2aba1dbabf 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -133,7 +133,6 @@ static inline initcall_t initcall_from_entry(initcall_entry_t *entry)
 #endif
 
 extern initcall_entry_t __con_initcall_start[], __con_initcall_end[];
-extern initcall_entry_t __start_lsm_info[], __end_lsm_info[];
 
 /* Used for contructor calls. */
 typedef void (*ctor_fn_t)(void);
@@ -236,7 +235,6 @@ extern bool initcall_debug;
 	static exitcall_t __exitcall_##fn __exit_call = fn
 
 #define console_initcall(fn)	___define_initcall(fn,, .con_initcall)
-#define security_initcall(fn)	___define_initcall(fn,, .lsm_info)
 
 struct obs_kernel_param {
 	const char *str;
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 97a020c616ad..d13059feca09 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2039,6 +2039,18 @@ extern char *lsm_names;
 extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
+struct lsm_info {
+	int (*init)(void);	/* Required. */
+};
+
+extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
+
+#define security_initcall(lsm)						\
+	static struct lsm_info __lsm_##lsm				\
+		__used __section(.lsm_info.init)			\
+		__aligned(sizeof(unsigned long))			\
+		= { .init = lsm, }
+
 #ifdef CONFIG_SECURITY_SELINUX_DISABLE
 /*
  * Assuring the safety of deleting a security module is up to
diff --git a/include/linux/module.h b/include/linux/module.h
index f807f15bebbe..264979283756 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -123,7 +123,6 @@ extern void cleanup_module(void);
 #define late_initcall_sync(fn)		module_init(fn)
 
 #define console_initcall(fn)		module_init(fn)
-#define security_initcall(fn)		module_init(fn)
 
 /* Each module must use one module_init(). */
 #define module_init(initfn)					\
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 5a6810041e5c..70d21b566955 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -22,6 +22,7 @@
 #include <linux/file.h>
 #include <linux/uaccess.h>
 #include <linux/security.h>
+#include <linux/lsm_hooks.h>
 #include "integrity.h"
 
 static struct rb_root integrity_iint_tree = RB_ROOT;
diff --git a/security/security.c b/security/security.c
index 41a5da2c7faf..e74f46fba591 100644
--- a/security/security.c
+++ b/security/security.c
@@ -43,16 +43,12 @@ char *lsm_names;
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
 
-static void __init do_security_initcalls(void)
+static void __init major_lsm_init(void)
 {
-	initcall_t call;
-	initcall_entry_t *ce;
+	struct lsm_info *lsm;
 
-	ce = __start_lsm_info;
-	while (ce < __end_lsm_info) {
-		call = initcall_from_entry(ce);
-		call();
-		ce++;
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		lsm->init();
 	}
 }
 
@@ -82,7 +78,7 @@ int __init security_init(void)
 	/*
 	 * Load all the remaining security modules.
 	 */
-	do_security_initcalls();
+	major_lsm_init();
 
 	return 0;
 }
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 05/32] LSM: Convert from initcall to struct lsm_info
  2018-10-02  0:54 ` [PATCH security-next v4 05/32] LSM: Convert from initcall to struct lsm_info Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for doing more interesting LSM init probing, this converts
the existing initcall system into an explicit call into a function pointer
from a section-collected struct lsm_info array.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/linux/init.h      |  2 --
 include/linux/lsm_hooks.h | 12 ++++++++++++
 include/linux/module.h    |  1 -
 security/integrity/iint.c |  1 +
 security/security.c       | 14 +++++---------
 5 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/include/linux/init.h b/include/linux/init.h
index 77636539e77c..9c2aba1dbabf 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -133,7 +133,6 @@ static inline initcall_t initcall_from_entry(initcall_entry_t *entry)
 #endif
 
 extern initcall_entry_t __con_initcall_start[], __con_initcall_end[];
-extern initcall_entry_t __start_lsm_info[], __end_lsm_info[];
 
 /* Used for contructor calls. */
 typedef void (*ctor_fn_t)(void);
@@ -236,7 +235,6 @@ extern bool initcall_debug;
 	static exitcall_t __exitcall_##fn __exit_call = fn
 
 #define console_initcall(fn)	___define_initcall(fn,, .con_initcall)
-#define security_initcall(fn)	___define_initcall(fn,, .lsm_info)
 
 struct obs_kernel_param {
 	const char *str;
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 97a020c616ad..d13059feca09 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2039,6 +2039,18 @@ extern char *lsm_names;
 extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
+struct lsm_info {
+	int (*init)(void);	/* Required. */
+};
+
+extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
+
+#define security_initcall(lsm)						\
+	static struct lsm_info __lsm_##lsm				\
+		__used __section(.lsm_info.init)			\
+		__aligned(sizeof(unsigned long))			\
+		= { .init = lsm, }
+
 #ifdef CONFIG_SECURITY_SELINUX_DISABLE
 /*
  * Assuring the safety of deleting a security module is up to
diff --git a/include/linux/module.h b/include/linux/module.h
index f807f15bebbe..264979283756 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -123,7 +123,6 @@ extern void cleanup_module(void);
 #define late_initcall_sync(fn)		module_init(fn)
 
 #define console_initcall(fn)		module_init(fn)
-#define security_initcall(fn)		module_init(fn)
 
 /* Each module must use one module_init(). */
 #define module_init(initfn)					\
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 5a6810041e5c..70d21b566955 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -22,6 +22,7 @@
 #include <linux/file.h>
 #include <linux/uaccess.h>
 #include <linux/security.h>
+#include <linux/lsm_hooks.h>
 #include "integrity.h"
 
 static struct rb_root integrity_iint_tree = RB_ROOT;
diff --git a/security/security.c b/security/security.c
index 41a5da2c7faf..e74f46fba591 100644
--- a/security/security.c
+++ b/security/security.c
@@ -43,16 +43,12 @@ char *lsm_names;
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
 
-static void __init do_security_initcalls(void)
+static void __init major_lsm_init(void)
 {
-	initcall_t call;
-	initcall_entry_t *ce;
+	struct lsm_info *lsm;
 
-	ce = __start_lsm_info;
-	while (ce < __end_lsm_info) {
-		call = initcall_from_entry(ce);
-		call();
-		ce++;
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		lsm->init();
 	}
 }
 
@@ -82,7 +78,7 @@ int __init security_init(void)
 	/*
 	 * Load all the remaining security modules.
 	 */
-	do_security_initcalls();
+	major_lsm_init();
 
 	return 0;
 }
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 06/32] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (5 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 05/32] LSM: Convert from initcall to struct lsm_info Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:15   ` James Morris
  2018-10-02  0:54 ` [PATCH security-next v4 07/32] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
                   ` (25 subsequent siblings)
  32 siblings, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Since the struct lsm_info table is not an initcall, we can just move it
into INIT_DATA like all the other tables.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 arch/arc/kernel/vmlinux.lds.S        |  1 -
 arch/arm/kernel/vmlinux-xip.lds.S    |  1 -
 arch/arm64/kernel/vmlinux.lds.S      |  1 -
 arch/h8300/kernel/vmlinux.lds.S      |  1 -
 arch/microblaze/kernel/vmlinux.lds.S |  2 --
 arch/powerpc/kernel/vmlinux.lds.S    |  2 --
 arch/um/include/asm/common.lds.S     |  2 --
 arch/xtensa/kernel/vmlinux.lds.S     |  1 -
 include/asm-generic/vmlinux.lds.h    | 24 +++++++++++-------------
 9 files changed, 11 insertions(+), 24 deletions(-)

diff --git a/arch/arc/kernel/vmlinux.lds.S b/arch/arc/kernel/vmlinux.lds.S
index f35ed578e007..8fb16bdabdcf 100644
--- a/arch/arc/kernel/vmlinux.lds.S
+++ b/arch/arc/kernel/vmlinux.lds.S
@@ -71,7 +71,6 @@ SECTIONS
 		INIT_SETUP(L1_CACHE_BYTES)
 		INIT_CALLS
 		CON_INITCALL
-		SECURITY_INITCALL
 	}
 
 	.init.arch.info : {
diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
index 3593d5c1acd2..8c74037ade22 100644
--- a/arch/arm/kernel/vmlinux-xip.lds.S
+++ b/arch/arm/kernel/vmlinux-xip.lds.S
@@ -96,7 +96,6 @@ SECTIONS
 		INIT_SETUP(16)
 		INIT_CALLS
 		CON_INITCALL
-		SECURITY_INITCALL
 		INIT_RAM_FS
 	}
 
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 605d1b60469c..7d23d591b03c 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -166,7 +166,6 @@ SECTIONS
 		INIT_SETUP(16)
 		INIT_CALLS
 		CON_INITCALL
-		SECURITY_INITCALL
 		INIT_RAM_FS
 		*(.init.rodata.* .init.bss)	/* from the EFI stub */
 	}
diff --git a/arch/h8300/kernel/vmlinux.lds.S b/arch/h8300/kernel/vmlinux.lds.S
index 35716a3048de..49f716c0a1df 100644
--- a/arch/h8300/kernel/vmlinux.lds.S
+++ b/arch/h8300/kernel/vmlinux.lds.S
@@ -56,7 +56,6 @@ SECTIONS
 	__init_begin = .;
 	INIT_TEXT_SECTION(4)
 	INIT_DATA_SECTION(4)
-	SECURITY_INIT
 	__init_end = .;
 	_edata = . ;
 	_begin_data = LOADADDR(.data);
diff --git a/arch/microblaze/kernel/vmlinux.lds.S b/arch/microblaze/kernel/vmlinux.lds.S
index 289d0e7f3e3a..e1f3e8741292 100644
--- a/arch/microblaze/kernel/vmlinux.lds.S
+++ b/arch/microblaze/kernel/vmlinux.lds.S
@@ -117,8 +117,6 @@ SECTIONS {
 		CON_INITCALL
 	}
 
-	SECURITY_INIT
-
 	__init_end_before_initramfs = .;
 
 	.init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 07ae018e550e..105a976323aa 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -212,8 +212,6 @@ SECTIONS
 		CON_INITCALL
 	}
 
-	SECURITY_INIT
-
 	. = ALIGN(8);
 	__ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
 		__start___ftr_fixup = .;
diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S
index 7adb4e6b658a..4049f2c46387 100644
--- a/arch/um/include/asm/common.lds.S
+++ b/arch/um/include/asm/common.lds.S
@@ -53,8 +53,6 @@
 	CON_INITCALL
   }
 
-  SECURITY_INIT
-
   .exitcall : {
 	__exitcall_begin = .;
 	*(.exitcall.exit)
diff --git a/arch/xtensa/kernel/vmlinux.lds.S b/arch/xtensa/kernel/vmlinux.lds.S
index a1c3edb8ad56..b727b18a68ac 100644
--- a/arch/xtensa/kernel/vmlinux.lds.S
+++ b/arch/xtensa/kernel/vmlinux.lds.S
@@ -197,7 +197,6 @@ SECTIONS
     INIT_SETUP(XCHAL_ICACHE_LINESIZE)
     INIT_CALLS
     CON_INITCALL
-    SECURITY_INITCALL
     INIT_RAM_FS
   }
 
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 5079a969e612..b31ea8bdfef9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -203,6 +203,15 @@
 #define EARLYCON_TABLE()
 #endif
 
+#ifdef CONFIG_SECURITY
+#define LSM_TABLE()	. = ALIGN(8);					\
+			__start_lsm_info = .;				\
+			KEEP(*(.lsm_info.init))				\
+			__end_lsm_info = .;
+#else
+#define LSM_TABLE()
+#endif
+
 #define ___OF_TABLE(cfg, name)	_OF_TABLE_##cfg(name)
 #define __OF_TABLE(cfg, name)	___OF_TABLE(cfg, name)
 #define OF_TABLE(cfg, name)	__OF_TABLE(IS_ENABLED(cfg), name)
@@ -597,7 +606,8 @@
 	IRQCHIP_OF_MATCH_TABLE()					\
 	ACPI_PROBE_TABLE(irqchip)					\
 	ACPI_PROBE_TABLE(timer)						\
-	EARLYCON_TABLE()
+	EARLYCON_TABLE()						\
+	LSM_TABLE()
 
 #define INIT_TEXT							\
 	*(.init.text .init.text.*)					\
@@ -786,17 +796,6 @@
 		KEEP(*(.con_initcall.init))				\
 		__con_initcall_end = .;
 
-#define SECURITY_INITCALL						\
-		__start_lsm_info = .;					\
-		KEEP(*(.lsm_info.init))					\
-		__end_lsm_info = .;
-
-/* Older linker script style for security init. */
-#define SECURITY_INIT							\
-	.lsm_info.init : AT(ADDR(.lsm_info.init) - LOAD_OFFSET) {	\
-		LSM_INFO						\
-	}
-
 #ifdef CONFIG_BLK_DEV_INITRD
 #define INIT_RAM_FS							\
 	. = ALIGN(4);							\
@@ -963,7 +962,6 @@
 		INIT_SETUP(initsetup_align)				\
 		INIT_CALLS						\
 		CON_INITCALL						\
-		SECURITY_INITCALL					\
 		INIT_RAM_FS						\
 	}
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 06/32] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
  2018-10-02  0:54 ` [PATCH security-next v4 06/32] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:15   ` James Morris
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Since the struct lsm_info table is not an initcall, we can just move it
into INIT_DATA like all the other tables.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 arch/arc/kernel/vmlinux.lds.S        |  1 -
 arch/arm/kernel/vmlinux-xip.lds.S    |  1 -
 arch/arm64/kernel/vmlinux.lds.S      |  1 -
 arch/h8300/kernel/vmlinux.lds.S      |  1 -
 arch/microblaze/kernel/vmlinux.lds.S |  2 --
 arch/powerpc/kernel/vmlinux.lds.S    |  2 --
 arch/um/include/asm/common.lds.S     |  2 --
 arch/xtensa/kernel/vmlinux.lds.S     |  1 -
 include/asm-generic/vmlinux.lds.h    | 24 +++++++++++-------------
 9 files changed, 11 insertions(+), 24 deletions(-)

diff --git a/arch/arc/kernel/vmlinux.lds.S b/arch/arc/kernel/vmlinux.lds.S
index f35ed578e007..8fb16bdabdcf 100644
--- a/arch/arc/kernel/vmlinux.lds.S
+++ b/arch/arc/kernel/vmlinux.lds.S
@@ -71,7 +71,6 @@ SECTIONS
 		INIT_SETUP(L1_CACHE_BYTES)
 		INIT_CALLS
 		CON_INITCALL
-		SECURITY_INITCALL
 	}
 
 	.init.arch.info : {
diff --git a/arch/arm/kernel/vmlinux-xip.lds.S b/arch/arm/kernel/vmlinux-xip.lds.S
index 3593d5c1acd2..8c74037ade22 100644
--- a/arch/arm/kernel/vmlinux-xip.lds.S
+++ b/arch/arm/kernel/vmlinux-xip.lds.S
@@ -96,7 +96,6 @@ SECTIONS
 		INIT_SETUP(16)
 		INIT_CALLS
 		CON_INITCALL
-		SECURITY_INITCALL
 		INIT_RAM_FS
 	}
 
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 605d1b60469c..7d23d591b03c 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -166,7 +166,6 @@ SECTIONS
 		INIT_SETUP(16)
 		INIT_CALLS
 		CON_INITCALL
-		SECURITY_INITCALL
 		INIT_RAM_FS
 		*(.init.rodata.* .init.bss)	/* from the EFI stub */
 	}
diff --git a/arch/h8300/kernel/vmlinux.lds.S b/arch/h8300/kernel/vmlinux.lds.S
index 35716a3048de..49f716c0a1df 100644
--- a/arch/h8300/kernel/vmlinux.lds.S
+++ b/arch/h8300/kernel/vmlinux.lds.S
@@ -56,7 +56,6 @@ SECTIONS
 	__init_begin = .;
 	INIT_TEXT_SECTION(4)
 	INIT_DATA_SECTION(4)
-	SECURITY_INIT
 	__init_end = .;
 	_edata = . ;
 	_begin_data = LOADADDR(.data);
diff --git a/arch/microblaze/kernel/vmlinux.lds.S b/arch/microblaze/kernel/vmlinux.lds.S
index 289d0e7f3e3a..e1f3e8741292 100644
--- a/arch/microblaze/kernel/vmlinux.lds.S
+++ b/arch/microblaze/kernel/vmlinux.lds.S
@@ -117,8 +117,6 @@ SECTIONS {
 		CON_INITCALL
 	}
 
-	SECURITY_INIT
-
 	__init_end_before_initramfs = .;
 
 	.init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 07ae018e550e..105a976323aa 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -212,8 +212,6 @@ SECTIONS
 		CON_INITCALL
 	}
 
-	SECURITY_INIT
-
 	. = ALIGN(8);
 	__ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
 		__start___ftr_fixup = .;
diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S
index 7adb4e6b658a..4049f2c46387 100644
--- a/arch/um/include/asm/common.lds.S
+++ b/arch/um/include/asm/common.lds.S
@@ -53,8 +53,6 @@
 	CON_INITCALL
   }
 
-  SECURITY_INIT
-
   .exitcall : {
 	__exitcall_begin = .;
 	*(.exitcall.exit)
diff --git a/arch/xtensa/kernel/vmlinux.lds.S b/arch/xtensa/kernel/vmlinux.lds.S
index a1c3edb8ad56..b727b18a68ac 100644
--- a/arch/xtensa/kernel/vmlinux.lds.S
+++ b/arch/xtensa/kernel/vmlinux.lds.S
@@ -197,7 +197,6 @@ SECTIONS
     INIT_SETUP(XCHAL_ICACHE_LINESIZE)
     INIT_CALLS
     CON_INITCALL
-    SECURITY_INITCALL
     INIT_RAM_FS
   }
 
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 5079a969e612..b31ea8bdfef9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -203,6 +203,15 @@
 #define EARLYCON_TABLE()
 #endif
 
+#ifdef CONFIG_SECURITY
+#define LSM_TABLE()	. = ALIGN(8);					\
+			__start_lsm_info = .;				\
+			KEEP(*(.lsm_info.init))				\
+			__end_lsm_info = .;
+#else
+#define LSM_TABLE()
+#endif
+
 #define ___OF_TABLE(cfg, name)	_OF_TABLE_##cfg(name)
 #define __OF_TABLE(cfg, name)	___OF_TABLE(cfg, name)
 #define OF_TABLE(cfg, name)	__OF_TABLE(IS_ENABLED(cfg), name)
@@ -597,7 +606,8 @@
 	IRQCHIP_OF_MATCH_TABLE()					\
 	ACPI_PROBE_TABLE(irqchip)					\
 	ACPI_PROBE_TABLE(timer)						\
-	EARLYCON_TABLE()
+	EARLYCON_TABLE()						\
+	LSM_TABLE()
 
 #define INIT_TEXT							\
 	*(.init.text .init.text.*)					\
@@ -786,17 +796,6 @@
 		KEEP(*(.con_initcall.init))				\
 		__con_initcall_end = .;
 
-#define SECURITY_INITCALL						\
-		__start_lsm_info = .;					\
-		KEEP(*(.lsm_info.init))					\
-		__end_lsm_info = .;
-
-/* Older linker script style for security init. */
-#define SECURITY_INIT							\
-	.lsm_info.init : AT(ADDR(.lsm_info.init) - LOAD_OFFSET) {	\
-		LSM_INFO						\
-	}
-
 #ifdef CONFIG_BLK_DEV_INITRD
 #define INIT_RAM_FS							\
 	. = ALIGN(4);							\
@@ -963,7 +962,6 @@
 		INIT_SETUP(initsetup_align)				\
 		INIT_CALLS						\
 		CON_INITCALL						\
-		SECURITY_INITCALL					\
 		INIT_RAM_FS						\
 	}
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 07/32] LSM: Convert security_initcall() into DEFINE_LSM()
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (6 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 06/32] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:16   ` James Morris
  2018-10-02  0:54 ` [PATCH security-next v4 08/32] LSM: Record LSM name in struct lsm_info Kees Cook
                   ` (24 subsequent siblings)
  32 siblings, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Instead of using argument-based initializers, switch to defining the
contents of struct lsm_info on a per-LSM basis. This also drops
the final use of the now inaccurate "initcall" naming.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h  | 5 ++---
 security/apparmor/lsm.c    | 4 +++-
 security/integrity/iint.c  | 4 +++-
 security/selinux/hooks.c   | 4 +++-
 security/smack/smack_lsm.c | 4 +++-
 security/tomoyo/tomoyo.c   | 4 +++-
 6 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index d13059feca09..9c6b4198ff5a 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2045,11 +2045,10 @@ struct lsm_info {
 
 extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
 
-#define security_initcall(lsm)						\
+#define DEFINE_LSM(lsm)							\
 	static struct lsm_info __lsm_##lsm				\
 		__used __section(.lsm_info.init)			\
-		__aligned(sizeof(unsigned long))			\
-		= { .init = lsm, }
+		__aligned(sizeof(unsigned long))
 
 #ifdef CONFIG_SECURITY_SELINUX_DISABLE
 /*
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 8b8b70620bbe..c4863956c832 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1606,4 +1606,6 @@ static int __init apparmor_init(void)
 	return error;
 }
 
-security_initcall(apparmor_init);
+DEFINE_LSM(apparmor) = {
+	.init = apparmor_init,
+};
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 70d21b566955..94e8e1820748 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -175,7 +175,9 @@ static int __init integrity_iintcache_init(void)
 			      0, SLAB_PANIC, init_once);
 	return 0;
 }
-security_initcall(integrity_iintcache_init);
+DEFINE_LSM(integrity) = {
+	.init = integrity_iintcache_init,
+};
 
 
 /*
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index ad9a9b8e9979..6ca2e89ddbd6 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7202,7 +7202,9 @@ void selinux_complete_init(void)
 
 /* SELinux requires early initialization in order to label
    all processes and objects when they are created. */
-security_initcall(selinux_init);
+DEFINE_LSM(selinux) = {
+	.init = selinux_init,
+};
 
 #if defined(CONFIG_NETFILTER)
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 340fc30ad85d..c62e26939a69 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4882,4 +4882,6 @@ static __init int smack_init(void)
  * Smack requires early initialization in order to label
  * all processes and objects when they are created.
  */
-security_initcall(smack_init);
+DEFINE_LSM(smack) = {
+	.init = smack_init,
+};
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 9f932e2d6852..b2d833999910 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -550,4 +550,6 @@ static int __init tomoyo_init(void)
 	return 0;
 }
 
-security_initcall(tomoyo_init);
+DEFINE_LSM(tomoyo) = {
+	.init = tomoyo_init,
+};
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 07/32] LSM: Convert security_initcall() into DEFINE_LSM()
  2018-10-02  0:54 ` [PATCH security-next v4 07/32] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:16   ` James Morris
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Instead of using argument-based initializers, switch to defining the
contents of struct lsm_info on a per-LSM basis. This also drops
the final use of the now inaccurate "initcall" naming.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h  | 5 ++---
 security/apparmor/lsm.c    | 4 +++-
 security/integrity/iint.c  | 4 +++-
 security/selinux/hooks.c   | 4 +++-
 security/smack/smack_lsm.c | 4 +++-
 security/tomoyo/tomoyo.c   | 4 +++-
 6 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index d13059feca09..9c6b4198ff5a 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2045,11 +2045,10 @@ struct lsm_info {
 
 extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
 
-#define security_initcall(lsm)						\
+#define DEFINE_LSM(lsm)							\
 	static struct lsm_info __lsm_##lsm				\
 		__used __section(.lsm_info.init)			\
-		__aligned(sizeof(unsigned long))			\
-		= { .init = lsm, }
+		__aligned(sizeof(unsigned long))
 
 #ifdef CONFIG_SECURITY_SELINUX_DISABLE
 /*
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 8b8b70620bbe..c4863956c832 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1606,4 +1606,6 @@ static int __init apparmor_init(void)
 	return error;
 }
 
-security_initcall(apparmor_init);
+DEFINE_LSM(apparmor) = {
+	.init = apparmor_init,
+};
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 70d21b566955..94e8e1820748 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -175,7 +175,9 @@ static int __init integrity_iintcache_init(void)
 			      0, SLAB_PANIC, init_once);
 	return 0;
 }
-security_initcall(integrity_iintcache_init);
+DEFINE_LSM(integrity) = {
+	.init = integrity_iintcache_init,
+};
 
 
 /*
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index ad9a9b8e9979..6ca2e89ddbd6 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7202,7 +7202,9 @@ void selinux_complete_init(void)
 
 /* SELinux requires early initialization in order to label
    all processes and objects when they are created. */
-security_initcall(selinux_init);
+DEFINE_LSM(selinux) = {
+	.init = selinux_init,
+};
 
 #if defined(CONFIG_NETFILTER)
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 340fc30ad85d..c62e26939a69 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4882,4 +4882,6 @@ static __init int smack_init(void)
  * Smack requires early initialization in order to label
  * all processes and objects when they are created.
  */
-security_initcall(smack_init);
+DEFINE_LSM(smack) = {
+	.init = smack_init,
+};
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 9f932e2d6852..b2d833999910 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -550,4 +550,6 @@ static int __init tomoyo_init(void)
 	return 0;
 }
 
-security_initcall(tomoyo_init);
+DEFINE_LSM(tomoyo) = {
+	.init = tomoyo_init,
+};
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 08/32] LSM: Record LSM name in struct lsm_info
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (7 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 07/32] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 09/32] LSM: Provide init debugging infrastructure Kees Cook
                   ` (23 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for making LSM selections outside of the LSMs, include
the name of LSMs in struct lsm_info.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h  | 1 +
 security/apparmor/lsm.c    | 1 +
 security/integrity/iint.c  | 1 +
 security/selinux/hooks.c   | 1 +
 security/smack/smack_lsm.c | 1 +
 security/tomoyo/tomoyo.c   | 1 +
 6 files changed, 6 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 9c6b4198ff5a..ae159b02f3ab 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2040,6 +2040,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
 struct lsm_info {
+	const char *name;	/* Required. */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index c4863956c832..dca4b7dbf368 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1607,5 +1607,6 @@ static int __init apparmor_init(void)
 }
 
 DEFINE_LSM(apparmor) = {
+	.name = "apparmor",
 	.init = apparmor_init,
 };
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 94e8e1820748..1ea05da2323d 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -176,6 +176,7 @@ static int __init integrity_iintcache_init(void)
 	return 0;
 }
 DEFINE_LSM(integrity) = {
+	.name = "integrity",
 	.init = integrity_iintcache_init,
 };
 
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6ca2e89ddbd6..9651bccae270 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7203,6 +7203,7 @@ void selinux_complete_init(void)
 /* SELinux requires early initialization in order to label
    all processes and objects when they are created. */
 DEFINE_LSM(selinux) = {
+	.name = "selinux",
 	.init = selinux_init,
 };
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index c62e26939a69..2fb56bcf1316 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4883,5 +4883,6 @@ static __init int smack_init(void)
  * all processes and objects when they are created.
  */
 DEFINE_LSM(smack) = {
+	.name = "smack",
 	.init = smack_init,
 };
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index b2d833999910..1b5b5097efd7 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -551,5 +551,6 @@ static int __init tomoyo_init(void)
 }
 
 DEFINE_LSM(tomoyo) = {
+	.name = "tomoyo",
 	.init = tomoyo_init,
 };
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 08/32] LSM: Record LSM name in struct lsm_info
  2018-10-02  0:54 ` [PATCH security-next v4 08/32] LSM: Record LSM name in struct lsm_info Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for making LSM selections outside of the LSMs, include
the name of LSMs in struct lsm_info.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h  | 1 +
 security/apparmor/lsm.c    | 1 +
 security/integrity/iint.c  | 1 +
 security/selinux/hooks.c   | 1 +
 security/smack/smack_lsm.c | 1 +
 security/tomoyo/tomoyo.c   | 1 +
 6 files changed, 6 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 9c6b4198ff5a..ae159b02f3ab 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2040,6 +2040,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
 struct lsm_info {
+	const char *name;	/* Required. */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index c4863956c832..dca4b7dbf368 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1607,5 +1607,6 @@ static int __init apparmor_init(void)
 }
 
 DEFINE_LSM(apparmor) = {
+	.name = "apparmor",
 	.init = apparmor_init,
 };
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 94e8e1820748..1ea05da2323d 100644
--- a/security/integrity/iint.c
+++ b/security/integrity/iint.c
@@ -176,6 +176,7 @@ static int __init integrity_iintcache_init(void)
 	return 0;
 }
 DEFINE_LSM(integrity) = {
+	.name = "integrity",
 	.init = integrity_iintcache_init,
 };
 
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 6ca2e89ddbd6..9651bccae270 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7203,6 +7203,7 @@ void selinux_complete_init(void)
 /* SELinux requires early initialization in order to label
    all processes and objects when they are created. */
 DEFINE_LSM(selinux) = {
+	.name = "selinux",
 	.init = selinux_init,
 };
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index c62e26939a69..2fb56bcf1316 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4883,5 +4883,6 @@ static __init int smack_init(void)
  * all processes and objects when they are created.
  */
 DEFINE_LSM(smack) = {
+	.name = "smack",
 	.init = smack_init,
 };
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index b2d833999910..1b5b5097efd7 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -551,5 +551,6 @@ static int __init tomoyo_init(void)
 }
 
 DEFINE_LSM(tomoyo) = {
+	.name = "tomoyo",
 	.init = tomoyo_init,
 };
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 09/32] LSM: Provide init debugging infrastructure
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (8 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 08/32] LSM: Record LSM name in struct lsm_info Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:17   ` James Morris
  2018-10-02  0:54 ` [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures Kees Cook
                   ` (22 subsequent siblings)
  32 siblings, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Booting with "lsm.debug" will report future details on how LSM ordering
decisions are being made.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 .../admin-guide/kernel-parameters.txt          |  2 ++
 security/security.c                            | 18 ++++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 9871e649ffef..32d323ee9218 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2274,6 +2274,8 @@
 	ltpc=		[NET]
 			Format: <io>,<irq>,<dma>
 
+	lsm.debug	[SECURITY] Enable LSM initialization debugging output.
+
 	machvec=	[IA-64] Force the use of a particular machine-vector
 			(machvec) in a generic kernel.
 			Example: machvec=hpzx1_swiotlb
diff --git a/security/security.c b/security/security.c
index e74f46fba591..395f804f6a91 100644
--- a/security/security.c
+++ b/security/security.c
@@ -12,6 +12,8 @@
  *	(at your option) any later version.
  */
 
+#define pr_fmt(fmt) "LSM: " fmt
+
 #include <linux/bpf.h>
 #include <linux/capability.h>
 #include <linux/dcache.h>
@@ -43,11 +45,19 @@ char *lsm_names;
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
 
+static __initdata bool debug;
+#define init_debug(...)						\
+	do {							\
+		if (debug)					\
+			pr_info(__VA_ARGS__);			\
+	} while (0)
+
 static void __init major_lsm_init(void)
 {
 	struct lsm_info *lsm;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		init_debug("initializing %s\n", lsm->name);
 		lsm->init();
 	}
 }
@@ -91,6 +101,14 @@ static int __init choose_lsm(char *str)
 }
 __setup("security=", choose_lsm);
 
+/* Enable LSM order debugging. */
+static int __init enable_debug(char *str)
+{
+	debug = true;
+	return 1;
+}
+__setup("lsm.debug", enable_debug);
+
 static bool match_last_lsm(const char *list, const char *lsm)
 {
 	const char *last;
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 09/32] LSM: Provide init debugging infrastructure
  2018-10-02  0:54 ` [PATCH security-next v4 09/32] LSM: Provide init debugging infrastructure Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:17   ` James Morris
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Booting with "lsm.debug" will report future details on how LSM ordering
decisions are being made.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 .../admin-guide/kernel-parameters.txt          |  2 ++
 security/security.c                            | 18 ++++++++++++++++++
 2 files changed, 20 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 9871e649ffef..32d323ee9218 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2274,6 +2274,8 @@
 	ltpc=		[NET]
 			Format: <io>,<irq>,<dma>
 
+	lsm.debug	[SECURITY] Enable LSM initialization debugging output.
+
 	machvec=	[IA-64] Force the use of a particular machine-vector
 			(machvec) in a generic kernel.
 			Example: machvec=hpzx1_swiotlb
diff --git a/security/security.c b/security/security.c
index e74f46fba591..395f804f6a91 100644
--- a/security/security.c
+++ b/security/security.c
@@ -12,6 +12,8 @@
  *	(at your option) any later version.
  */
 
+#define pr_fmt(fmt) "LSM: " fmt
+
 #include <linux/bpf.h>
 #include <linux/capability.h>
 #include <linux/dcache.h>
@@ -43,11 +45,19 @@ char *lsm_names;
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
 
+static __initdata bool debug;
+#define init_debug(...)						\
+	do {							\
+		if (debug)					\
+			pr_info(__VA_ARGS__);			\
+	} while (0)
+
 static void __init major_lsm_init(void)
 {
 	struct lsm_info *lsm;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		init_debug("initializing %s\n", lsm->name);
 		lsm->init();
 	}
 }
@@ -91,6 +101,14 @@ static int __init choose_lsm(char *str)
 }
 __setup("security=", choose_lsm);
 
+/* Enable LSM order debugging. */
+static int __init enable_debug(char *str)
+{
+	debug = true;
+	return 1;
+}
+__setup("lsm.debug", enable_debug);
+
 static bool match_last_lsm(const char *list, const char *lsm)
 {
 	const char *last;
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (9 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 09/32] LSM: Provide init debugging infrastructure Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:20   ` James Morris
  2018-10-02  0:54 ` [PATCH security-next v4 11/32] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
                   ` (21 subsequent siblings)
  32 siblings, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

LSM initialization failures have traditionally been ignored. We should
at least WARN when something goes wrong.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security/security.c b/security/security.c
index 395f804f6a91..2055af907eba 100644
--- a/security/security.c
+++ b/security/security.c
@@ -55,10 +55,12 @@ static __initdata bool debug;
 static void __init major_lsm_init(void)
 {
 	struct lsm_info *lsm;
+	int ret;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
 		init_debug("initializing %s\n", lsm->name);
-		lsm->init();
+		ret = lsm->init();
+		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
 	}
 }
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures
  2018-10-02  0:54 ` [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  2018-10-02 21:20   ` James Morris
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

LSM initialization failures have traditionally been ignored. We should
at least WARN when something goes wrong.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security/security.c b/security/security.c
index 395f804f6a91..2055af907eba 100644
--- a/security/security.c
+++ b/security/security.c
@@ -55,10 +55,12 @@ static __initdata bool debug;
 static void __init major_lsm_init(void)
 {
 	struct lsm_info *lsm;
+	int ret;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
 		init_debug("initializing %s\n", lsm->name);
-		lsm->init();
+		ret = lsm->init();
+		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
 	}
 }
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 11/32] LSM: Introduce LSM_FLAG_LEGACY_MAJOR
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (10 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 12/32] LSM: Provide separate ordered initialization Kees Cook
                   ` (20 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This adds a flag for the current "major" LSMs to distinguish them when
we have a universal method for ordering all LSMs. It's called "legacy"
since the distinction of "major" will go away in the blob-sharing world.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/linux/lsm_hooks.h  | 3 +++
 security/apparmor/lsm.c    | 1 +
 security/selinux/hooks.c   | 1 +
 security/smack/smack_lsm.c | 1 +
 security/tomoyo/tomoyo.c   | 1 +
 5 files changed, 7 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index ae159b02f3ab..531e219a49b9 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2039,8 +2039,11 @@ extern char *lsm_names;
 extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
+#define LSM_FLAG_LEGACY_MAJOR	BIT(0)
+
 struct lsm_info {
 	const char *name;	/* Required. */
+	unsigned long flags;	/* Optional: flags describing LSM */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index dca4b7dbf368..768cb539fb6c 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1608,5 +1608,6 @@ static int __init apparmor_init(void)
 
 DEFINE_LSM(apparmor) = {
 	.name = "apparmor",
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = apparmor_init,
 };
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9651bccae270..020886895819 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7204,6 +7204,7 @@ void selinux_complete_init(void)
    all processes and objects when they are created. */
 DEFINE_LSM(selinux) = {
 	.name = "selinux",
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = selinux_init,
 };
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 2fb56bcf1316..db8bc6b6d8b0 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4884,5 +4884,6 @@ static __init int smack_init(void)
  */
 DEFINE_LSM(smack) = {
 	.name = "smack",
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = smack_init,
 };
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 1b5b5097efd7..09f7af130d3a 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -552,5 +552,6 @@ static int __init tomoyo_init(void)
 
 DEFINE_LSM(tomoyo) = {
 	.name = "tomoyo",
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = tomoyo_init,
 };
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 11/32] LSM: Introduce LSM_FLAG_LEGACY_MAJOR
  2018-10-02  0:54 ` [PATCH security-next v4 11/32] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This adds a flag for the current "major" LSMs to distinguish them when
we have a universal method for ordering all LSMs. It's called "legacy"
since the distinction of "major" will go away in the blob-sharing world.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/linux/lsm_hooks.h  | 3 +++
 security/apparmor/lsm.c    | 1 +
 security/selinux/hooks.c   | 1 +
 security/smack/smack_lsm.c | 1 +
 security/tomoyo/tomoyo.c   | 1 +
 5 files changed, 7 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index ae159b02f3ab..531e219a49b9 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2039,8 +2039,11 @@ extern char *lsm_names;
 extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
+#define LSM_FLAG_LEGACY_MAJOR	BIT(0)
+
 struct lsm_info {
 	const char *name;	/* Required. */
+	unsigned long flags;	/* Optional: flags describing LSM */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index dca4b7dbf368..768cb539fb6c 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1608,5 +1608,6 @@ static int __init apparmor_init(void)
 
 DEFINE_LSM(apparmor) = {
 	.name = "apparmor",
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = apparmor_init,
 };
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 9651bccae270..020886895819 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7204,6 +7204,7 @@ void selinux_complete_init(void)
    all processes and objects when they are created. */
 DEFINE_LSM(selinux) = {
 	.name = "selinux",
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = selinux_init,
 };
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 2fb56bcf1316..db8bc6b6d8b0 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4884,5 +4884,6 @@ static __init int smack_init(void)
  */
 DEFINE_LSM(smack) = {
 	.name = "smack",
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = smack_init,
 };
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 1b5b5097efd7..09f7af130d3a 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -552,5 +552,6 @@ static int __init tomoyo_init(void)
 
 DEFINE_LSM(tomoyo) = {
 	.name = "tomoyo",
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = tomoyo_init,
 };
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 12/32] LSM: Provide separate ordered initialization
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (11 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 11/32] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce" Kees Cook
                   ` (19 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This provides a place for ordered LSMs to be initialized, separate from
the "major" LSMs. This is mainly a copy/paste from major_lsm_init() to
ordered_lsm_init(), but it will change drastically in later patches.

What is not obvious in the patch is that this change moves the integrity
LSM from major_lsm_init() into ordered_lsm_init(), since it is not marked
with the LSM_FLAG_LEGACY_MAJOR. As it is the only LSM in the "ordered"
list, there is no reordering yet created.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/security/security.c b/security/security.c
index 2055af907eba..ebbbb672ced5 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,12 +52,30 @@ static __initdata bool debug;
 			pr_info(__VA_ARGS__);			\
 	} while (0)
 
+static void __init ordered_lsm_init(void)
+{
+	struct lsm_info *lsm;
+	int ret;
+
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) != 0)
+			continue;
+
+		init_debug("initializing %s\n", lsm->name);
+		ret = lsm->init();
+		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
+	}
+}
+
 static void __init major_lsm_init(void)
 {
 	struct lsm_info *lsm;
 	int ret;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
+			continue;
+
 		init_debug("initializing %s\n", lsm->name);
 		ret = lsm->init();
 		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
@@ -87,6 +105,9 @@ int __init security_init(void)
 	yama_add_hooks();
 	loadpin_add_hooks();
 
+	/* Load LSMs in specified order. */
+	ordered_lsm_init();
+
 	/*
 	 * Load all the remaining security modules.
 	 */
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 12/32] LSM: Provide separate ordered initialization
  2018-10-02  0:54 ` [PATCH security-next v4 12/32] LSM: Provide separate ordered initialization Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This provides a place for ordered LSMs to be initialized, separate from
the "major" LSMs. This is mainly a copy/paste from major_lsm_init() to
ordered_lsm_init(), but it will change drastically in later patches.

What is not obvious in the patch is that this change moves the integrity
LSM from major_lsm_init() into ordered_lsm_init(), since it is not marked
with the LSM_FLAG_LEGACY_MAJOR. As it is the only LSM in the "ordered"
list, there is no reordering yet created.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/security/security.c b/security/security.c
index 2055af907eba..ebbbb672ced5 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,12 +52,30 @@ static __initdata bool debug;
 			pr_info(__VA_ARGS__);			\
 	} while (0)
 
+static void __init ordered_lsm_init(void)
+{
+	struct lsm_info *lsm;
+	int ret;
+
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) != 0)
+			continue;
+
+		init_debug("initializing %s\n", lsm->name);
+		ret = lsm->init();
+		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
+	}
+}
+
 static void __init major_lsm_init(void)
 {
 	struct lsm_info *lsm;
 	int ret;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
+			continue;
+
 		init_debug("initializing %s\n", lsm->name);
 		ret = lsm->init();
 		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
@@ -87,6 +105,9 @@ int __init security_init(void)
 	yama_add_hooks();
 	loadpin_add_hooks();
 
+	/* Load LSMs in specified order. */
+	ordered_lsm_init();
+
 	/*
 	 * Load all the remaining security modules.
 	 */
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce"
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (12 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 12/32] LSM: Provide separate ordered initialization Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  1:06   ` Randy Dunlap
  2018-10-02  0:54 ` [PATCH security-next v4 14/32] LSM: Plumb visibility into optional "enabled" state Kees Cook
                   ` (18 subsequent siblings)
  32 siblings, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

LoadPin's "enable" setting is really about enforcement, not whether
or not the LSM is using LSM hooks. Instead, split this out so that LSM
enabling can be logically distinct from whether enforcement is happening
(for example, the pinning happens when the LSM is enabled, but the pin
is only checked when "enforce" is set). This allows LoadPin to continue
to operate sanely in test environments once LSM enable/disable is
centrally handled (i.e. we want LoadPin to be enabled separately from
its enforcement).

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/loadpin/Kconfig   |  4 ++--
 security/loadpin/loadpin.c | 21 +++++++++++----------
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/security/loadpin/Kconfig b/security/loadpin/Kconfig
index dd01aa91e521..8653608a3693 100644
--- a/security/loadpin/Kconfig
+++ b/security/loadpin/Kconfig
@@ -10,10 +10,10 @@ config SECURITY_LOADPIN
 	  have a root filesystem backed by a read-only device such as
 	  dm-verity or a CDROM.
 
-config SECURITY_LOADPIN_ENABLED
+config SECURITY_LOADPIN_ENFORCING
 	bool "Enforce LoadPin at boot"
 	depends on SECURITY_LOADPIN
 	help
 	  If selected, LoadPin will enforce pinning at boot. If not
 	  selected, it can be enabled at boot with the kernel parameter
-	  "loadpin.enabled=1".
+	  "loadpin.enforcing=1".
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 0716af28808a..d8a68a6f6fef 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -44,7 +44,7 @@ static void report_load(const char *origin, struct file *file, char *operation)
 	kfree(pathname);
 }
 
-static int enabled = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENABLED);
+static int enforcing = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCING);
 static struct super_block *pinned_root;
 static DEFINE_SPINLOCK(pinned_root_spinlock);
 
@@ -60,8 +60,8 @@ static struct ctl_path loadpin_sysctl_path[] = {
 
 static struct ctl_table loadpin_sysctl_table[] = {
 	{
-		.procname       = "enabled",
-		.data           = &enabled,
+		.procname       = "enforcing",
+		.data           = &enforcing,
 		.maxlen         = sizeof(int),
 		.mode           = 0644,
 		.proc_handler   = proc_dointvec_minmax,
@@ -97,7 +97,7 @@ static void check_pinning_enforcement(struct super_block *mnt_sb)
 					   loadpin_sysctl_table))
 			pr_notice("sysctl registration failed!\n");
 		else
-			pr_info("load pinning can be disabled.\n");
+			pr_info("enforcement can be disabled.\n");
 	} else
 		pr_info("load pinning engaged.\n");
 }
@@ -128,7 +128,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
 
 	/* This handles the older init_module API that has a NULL file. */
 	if (!file) {
-		if (!enabled) {
+		if (!enforcing) {
 			report_load(origin, NULL, "old-api-pinning-ignored");
 			return 0;
 		}
@@ -151,7 +151,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
 		 * Unlock now since it's only pinned_root we care about.
 		 * In the worst case, we will (correctly) report pinning
 		 * failures before we have announced that pinning is
-		 * enabled. This would be purely cosmetic.
+		 * enforcing. This would be purely cosmetic.
 		 */
 		spin_unlock(&pinned_root_spinlock);
 		check_pinning_enforcement(pinned_root);
@@ -161,7 +161,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
 	}
 
 	if (IS_ERR_OR_NULL(pinned_root) || load_root != pinned_root) {
-		if (unlikely(!enabled)) {
+		if (unlikely(!enforcing)) {
 			report_load(origin, file, "pinning-ignored");
 			return 0;
 		}
@@ -186,10 +186,11 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
 
 void __init loadpin_add_hooks(void)
 {
-	pr_info("ready to pin (currently %sabled)", enabled ? "en" : "dis");
+	pr_info("ready to pin (currently %senforcing)\n",
+		enforcing ? "" : "not ");
 	security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
 }
 
 /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
-module_param(enabled, int, 0);
-MODULE_PARM_DESC(enabled, "Pin module/firmware loading (default: true)");
+module_param(enforcing, int, 0);
+MODULE_PARM_DESC(enforcing, "Enforce module/firmware pinning");
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce"
  2018-10-02  0:54 ` [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce" Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  2018-10-02  1:06   ` Randy Dunlap
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

LoadPin's "enable" setting is really about enforcement, not whether
or not the LSM is using LSM hooks. Instead, split this out so that LSM
enabling can be logically distinct from whether enforcement is happening
(for example, the pinning happens when the LSM is enabled, but the pin
is only checked when "enforce" is set). This allows LoadPin to continue
to operate sanely in test environments once LSM enable/disable is
centrally handled (i.e. we want LoadPin to be enabled separately from
its enforcement).

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/loadpin/Kconfig   |  4 ++--
 security/loadpin/loadpin.c | 21 +++++++++++----------
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/security/loadpin/Kconfig b/security/loadpin/Kconfig
index dd01aa91e521..8653608a3693 100644
--- a/security/loadpin/Kconfig
+++ b/security/loadpin/Kconfig
@@ -10,10 +10,10 @@ config SECURITY_LOADPIN
 	  have a root filesystem backed by a read-only device such as
 	  dm-verity or a CDROM.
 
-config SECURITY_LOADPIN_ENABLED
+config SECURITY_LOADPIN_ENFORCING
 	bool "Enforce LoadPin at boot"
 	depends on SECURITY_LOADPIN
 	help
 	  If selected, LoadPin will enforce pinning at boot. If not
 	  selected, it can be enabled at boot with the kernel parameter
-	  "loadpin.enabled=1".
+	  "loadpin.enforcing=1".
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 0716af28808a..d8a68a6f6fef 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -44,7 +44,7 @@ static void report_load(const char *origin, struct file *file, char *operation)
 	kfree(pathname);
 }
 
-static int enabled = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENABLED);
+static int enforcing = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCING);
 static struct super_block *pinned_root;
 static DEFINE_SPINLOCK(pinned_root_spinlock);
 
@@ -60,8 +60,8 @@ static struct ctl_path loadpin_sysctl_path[] = {
 
 static struct ctl_table loadpin_sysctl_table[] = {
 	{
-		.procname       = "enabled",
-		.data           = &enabled,
+		.procname       = "enforcing",
+		.data           = &enforcing,
 		.maxlen         = sizeof(int),
 		.mode           = 0644,
 		.proc_handler   = proc_dointvec_minmax,
@@ -97,7 +97,7 @@ static void check_pinning_enforcement(struct super_block *mnt_sb)
 					   loadpin_sysctl_table))
 			pr_notice("sysctl registration failed!\n");
 		else
-			pr_info("load pinning can be disabled.\n");
+			pr_info("enforcement can be disabled.\n");
 	} else
 		pr_info("load pinning engaged.\n");
 }
@@ -128,7 +128,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
 
 	/* This handles the older init_module API that has a NULL file. */
 	if (!file) {
-		if (!enabled) {
+		if (!enforcing) {
 			report_load(origin, NULL, "old-api-pinning-ignored");
 			return 0;
 		}
@@ -151,7 +151,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
 		 * Unlock now since it's only pinned_root we care about.
 		 * In the worst case, we will (correctly) report pinning
 		 * failures before we have announced that pinning is
-		 * enabled. This would be purely cosmetic.
+		 * enforcing. This would be purely cosmetic.
 		 */
 		spin_unlock(&pinned_root_spinlock);
 		check_pinning_enforcement(pinned_root);
@@ -161,7 +161,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
 	}
 
 	if (IS_ERR_OR_NULL(pinned_root) || load_root != pinned_root) {
-		if (unlikely(!enabled)) {
+		if (unlikely(!enforcing)) {
 			report_load(origin, file, "pinning-ignored");
 			return 0;
 		}
@@ -186,10 +186,11 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
 
 void __init loadpin_add_hooks(void)
 {
-	pr_info("ready to pin (currently %sabled)", enabled ? "en" : "dis");
+	pr_info("ready to pin (currently %senforcing)\n",
+		enforcing ? "" : "not ");
 	security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
 }
 
 /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
-module_param(enabled, int, 0);
-MODULE_PARM_DESC(enabled, "Pin module/firmware loading (default: true)");
+module_param(enforcing, int, 0);
+MODULE_PARM_DESC(enforcing, "Enforce module/firmware pinning");
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 14/32] LSM: Plumb visibility into optional "enabled" state
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (13 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce" Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 15/32] LSM: Lift LSM selection out of individual LSMs Kees Cook
                   ` (17 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for lifting the "is this LSM enabled?" logic out of the
individual LSMs, pass in any special enabled state tracking (as needed
for SELinux, AppArmor, and LoadPin). This should be an "int" to include
handling any future cases where "enabled" is exposed via sysctl which
has no "bool" type.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/linux/lsm_hooks.h | 1 +
 security/apparmor/lsm.c   | 5 +++--
 security/selinux/hooks.c  | 1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 531e219a49b9..6ec5a0266f21 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2044,6 +2044,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 struct lsm_info {
 	const char *name;	/* Required. */
 	unsigned long flags;	/* Optional: flags describing LSM */
+	int *enabled;		/* Optional: NULL means enabled. */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 768cb539fb6c..6ace45704cb6 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1303,8 +1303,8 @@ bool aa_g_paranoid_load = true;
 module_param_named(paranoid_load, aa_g_paranoid_load, aabool, S_IRUGO);
 
 /* Boot time disable flag */
-static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
-module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
+static int apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
+module_param_named(enabled, apparmor_enabled, int, 0444);
 
 static int __init apparmor_enabled_setup(char *str)
 {
@@ -1609,5 +1609,6 @@ static int __init apparmor_init(void)
 DEFINE_LSM(apparmor) = {
 	.name = "apparmor",
 	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.enabled = &apparmor_enabled,
 	.init = apparmor_init,
 };
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 020886895819..e8da99550b67 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7205,6 +7205,7 @@ void selinux_complete_init(void)
 DEFINE_LSM(selinux) = {
 	.name = "selinux",
 	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.enabled = &selinux_enabled,
 	.init = selinux_init,
 };
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 14/32] LSM: Plumb visibility into optional "enabled" state
  2018-10-02  0:54 ` [PATCH security-next v4 14/32] LSM: Plumb visibility into optional "enabled" state Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for lifting the "is this LSM enabled?" logic out of the
individual LSMs, pass in any special enabled state tracking (as needed
for SELinux, AppArmor, and LoadPin). This should be an "int" to include
handling any future cases where "enabled" is exposed via sysctl which
has no "bool" type.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/linux/lsm_hooks.h | 1 +
 security/apparmor/lsm.c   | 5 +++--
 security/selinux/hooks.c  | 1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 531e219a49b9..6ec5a0266f21 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2044,6 +2044,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 struct lsm_info {
 	const char *name;	/* Required. */
 	unsigned long flags;	/* Optional: flags describing LSM */
+	int *enabled;		/* Optional: NULL means enabled. */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 768cb539fb6c..6ace45704cb6 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1303,8 +1303,8 @@ bool aa_g_paranoid_load = true;
 module_param_named(paranoid_load, aa_g_paranoid_load, aabool, S_IRUGO);
 
 /* Boot time disable flag */
-static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
-module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
+static int apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
+module_param_named(enabled, apparmor_enabled, int, 0444);
 
 static int __init apparmor_enabled_setup(char *str)
 {
@@ -1609,5 +1609,6 @@ static int __init apparmor_init(void)
 DEFINE_LSM(apparmor) = {
 	.name = "apparmor",
 	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.enabled = &apparmor_enabled,
 	.init = apparmor_init,
 };
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 020886895819..e8da99550b67 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7205,6 +7205,7 @@ void selinux_complete_init(void)
 DEFINE_LSM(selinux) = {
 	.name = "selinux",
 	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.enabled = &selinux_enabled,
 	.init = selinux_init,
 };
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 15/32] LSM: Lift LSM selection out of individual LSMs
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (14 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 14/32] LSM: Plumb visibility into optional "enabled" state Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 16/32] LSM: Prepare for arbitrary LSM enabling Kees Cook
                   ` (16 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

As a prerequisite to adjusting LSM selection logic in the future, this
moves the selection logic up out of the individual major LSMs, making
their init functions only run when actually enabled. This considers all
LSMs enabled by default unless they specified an external "enable"
variable.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/linux/lsm_hooks.h  |  1 -
 security/apparmor/lsm.c    |  6 ---
 security/security.c        | 84 ++++++++++++++++++++++++--------------
 security/selinux/hooks.c   | 10 -----
 security/smack/smack_lsm.c |  3 --
 security/tomoyo/tomoyo.c   |  2 -
 6 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 6ec5a0266f21..9ecb623fb39d 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2085,7 +2085,6 @@ static inline void security_delete_hooks(struct security_hook_list *hooks,
 #define __lsm_ro_after_init	__ro_after_init
 #endif /* CONFIG_SECURITY_WRITABLE_HOOKS */
 
-extern int __init security_module_enable(const char *module);
 extern void __init capability_add_hooks(void);
 #ifdef CONFIG_SECURITY_YAMA
 extern void __init yama_add_hooks(void);
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 6ace45704cb6..bc56b058dc75 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1542,12 +1542,6 @@ static int __init apparmor_init(void)
 {
 	int error;
 
-	if (!apparmor_enabled || !security_module_enable("apparmor")) {
-		aa_info_message("AppArmor disabled by boot time parameter");
-		apparmor_enabled = false;
-		return 0;
-	}
-
 	aa_secids_init();
 
 	error = aa_setup_dfa_engine();
diff --git a/security/security.c b/security/security.c
index ebbbb672ced5..4e5e67b82b7b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,33 +52,78 @@ static __initdata bool debug;
 			pr_info(__VA_ARGS__);			\
 	} while (0)
 
+static bool __init is_enabled(struct lsm_info *lsm)
+{
+	if (!lsm->enabled || *lsm->enabled)
+		return true;
+
+	return false;
+}
+
+/* Mark an LSM's enabled flag, if it exists. */
+static void __init set_enabled(struct lsm_info *lsm, bool enabled)
+{
+	if (lsm->enabled)
+		*lsm->enabled = enabled;
+}
+
+/* Is an LSM allowed to be initialized? */
+static bool __init lsm_allowed(struct lsm_info *lsm)
+{
+	/* Skip if the LSM is disabled. */
+	if (!is_enabled(lsm))
+		return false;
+
+	/* Skip major-specific checks if not a major LSM. */
+	if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
+		return true;
+
+	/* Disabled if this LSM isn't the chosen one. */
+	if (strcmp(lsm->name, chosen_lsm) != 0)
+		return false;
+
+	return true;
+}
+
+/* Check if LSM should be enabled. Mark any that are disabled. */
+static void __init maybe_initialize_lsm(struct lsm_info *lsm)
+{
+	int enabled = lsm_allowed(lsm);
+
+	/* Record enablement. */
+	set_enabled(lsm, enabled);
+
+	/* If selected, initialize the LSM. */
+	if (enabled) {
+		int ret;
+
+		init_debug("initializing %s\n", lsm->name);
+		ret = lsm->init();
+		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
+	}
+}
+
 static void __init ordered_lsm_init(void)
 {
 	struct lsm_info *lsm;
-	int ret;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
 		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) != 0)
 			continue;
 
-		init_debug("initializing %s\n", lsm->name);
-		ret = lsm->init();
-		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
+		maybe_initialize_lsm(lsm);
 	}
 }
 
 static void __init major_lsm_init(void)
 {
 	struct lsm_info *lsm;
-	int ret;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
 		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
 			continue;
 
-		init_debug("initializing %s\n", lsm->name);
-		ret = lsm->init();
-		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
+		maybe_initialize_lsm(lsm);
 	}
 }
 
@@ -168,29 +213,6 @@ static int lsm_append(char *new, char **result)
 	return 0;
 }
 
-/**
- * security_module_enable - Load given security module on boot ?
- * @module: the name of the module
- *
- * Each LSM must pass this method before registering its own operations
- * to avoid security registration races. This method may also be used
- * to check if your LSM is currently loaded during kernel initialization.
- *
- * Returns:
- *
- * true if:
- *
- * - The passed LSM is the one chosen by user at boot time,
- * - or the passed LSM is configured as the default and the user did not
- *   choose an alternate LSM at boot time.
- *
- * Otherwise, return false.
- */
-int __init security_module_enable(const char *module)
-{
-	return !strcmp(module, chosen_lsm);
-}
-
 /**
  * security_add_hooks - Add a modules hooks to the hook lists.
  * @hooks: the hooks to add
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e8da99550b67..71a10fedecb3 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7133,16 +7133,6 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = {
 
 static __init int selinux_init(void)
 {
-	if (!security_module_enable("selinux")) {
-		selinux_enabled = 0;
-		return 0;
-	}
-
-	if (!selinux_enabled) {
-		pr_info("SELinux:  Disabled at boot.\n");
-		return 0;
-	}
-
 	pr_info("SELinux:  Initializing.\n");
 
 	memset(&selinux_state, 0, sizeof(selinux_state));
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index db8bc6b6d8b0..f243044d5a55 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4834,9 +4834,6 @@ static __init int smack_init(void)
 	struct cred *cred;
 	struct task_smack *tsp;
 
-	if (!security_module_enable("smack"))
-		return 0;
-
 	smack_inode_cache = KMEM_CACHE(inode_smack, 0);
 	if (!smack_inode_cache)
 		return -ENOMEM;
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 09f7af130d3a..a46f6bc1e97c 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -540,8 +540,6 @@ static int __init tomoyo_init(void)
 {
 	struct cred *cred = (struct cred *) current_cred();
 
-	if (!security_module_enable("tomoyo"))
-		return 0;
 	/* register ourselves with the security framework */
 	security_add_hooks(tomoyo_hooks, ARRAY_SIZE(tomoyo_hooks), "tomoyo");
 	printk(KERN_INFO "TOMOYO Linux initialized\n");
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 15/32] LSM: Lift LSM selection out of individual LSMs
  2018-10-02  0:54 ` [PATCH security-next v4 15/32] LSM: Lift LSM selection out of individual LSMs Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

As a prerequisite to adjusting LSM selection logic in the future, this
moves the selection logic up out of the individual major LSMs, making
their init functions only run when actually enabled. This considers all
LSMs enabled by default unless they specified an external "enable"
variable.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 include/linux/lsm_hooks.h  |  1 -
 security/apparmor/lsm.c    |  6 ---
 security/security.c        | 84 ++++++++++++++++++++++++--------------
 security/selinux/hooks.c   | 10 -----
 security/smack/smack_lsm.c |  3 --
 security/tomoyo/tomoyo.c   |  2 -
 6 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 6ec5a0266f21..9ecb623fb39d 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2085,7 +2085,6 @@ static inline void security_delete_hooks(struct security_hook_list *hooks,
 #define __lsm_ro_after_init	__ro_after_init
 #endif /* CONFIG_SECURITY_WRITABLE_HOOKS */
 
-extern int __init security_module_enable(const char *module);
 extern void __init capability_add_hooks(void);
 #ifdef CONFIG_SECURITY_YAMA
 extern void __init yama_add_hooks(void);
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 6ace45704cb6..bc56b058dc75 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1542,12 +1542,6 @@ static int __init apparmor_init(void)
 {
 	int error;
 
-	if (!apparmor_enabled || !security_module_enable("apparmor")) {
-		aa_info_message("AppArmor disabled by boot time parameter");
-		apparmor_enabled = false;
-		return 0;
-	}
-
 	aa_secids_init();
 
 	error = aa_setup_dfa_engine();
diff --git a/security/security.c b/security/security.c
index ebbbb672ced5..4e5e67b82b7b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,33 +52,78 @@ static __initdata bool debug;
 			pr_info(__VA_ARGS__);			\
 	} while (0)
 
+static bool __init is_enabled(struct lsm_info *lsm)
+{
+	if (!lsm->enabled || *lsm->enabled)
+		return true;
+
+	return false;
+}
+
+/* Mark an LSM's enabled flag, if it exists. */
+static void __init set_enabled(struct lsm_info *lsm, bool enabled)
+{
+	if (lsm->enabled)
+		*lsm->enabled = enabled;
+}
+
+/* Is an LSM allowed to be initialized? */
+static bool __init lsm_allowed(struct lsm_info *lsm)
+{
+	/* Skip if the LSM is disabled. */
+	if (!is_enabled(lsm))
+		return false;
+
+	/* Skip major-specific checks if not a major LSM. */
+	if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
+		return true;
+
+	/* Disabled if this LSM isn't the chosen one. */
+	if (strcmp(lsm->name, chosen_lsm) != 0)
+		return false;
+
+	return true;
+}
+
+/* Check if LSM should be enabled. Mark any that are disabled. */
+static void __init maybe_initialize_lsm(struct lsm_info *lsm)
+{
+	int enabled = lsm_allowed(lsm);
+
+	/* Record enablement. */
+	set_enabled(lsm, enabled);
+
+	/* If selected, initialize the LSM. */
+	if (enabled) {
+		int ret;
+
+		init_debug("initializing %s\n", lsm->name);
+		ret = lsm->init();
+		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
+	}
+}
+
 static void __init ordered_lsm_init(void)
 {
 	struct lsm_info *lsm;
-	int ret;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
 		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) != 0)
 			continue;
 
-		init_debug("initializing %s\n", lsm->name);
-		ret = lsm->init();
-		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
+		maybe_initialize_lsm(lsm);
 	}
 }
 
 static void __init major_lsm_init(void)
 {
 	struct lsm_info *lsm;
-	int ret;
 
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
 		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
 			continue;
 
-		init_debug("initializing %s\n", lsm->name);
-		ret = lsm->init();
-		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
+		maybe_initialize_lsm(lsm);
 	}
 }
 
@@ -168,29 +213,6 @@ static int lsm_append(char *new, char **result)
 	return 0;
 }
 
-/**
- * security_module_enable - Load given security module on boot ?
- * @module: the name of the module
- *
- * Each LSM must pass this method before registering its own operations
- * to avoid security registration races. This method may also be used
- * to check if your LSM is currently loaded during kernel initialization.
- *
- * Returns:
- *
- * true if:
- *
- * - The passed LSM is the one chosen by user at boot time,
- * - or the passed LSM is configured as the default and the user did not
- *   choose an alternate LSM at boot time.
- *
- * Otherwise, return false.
- */
-int __init security_module_enable(const char *module)
-{
-	return !strcmp(module, chosen_lsm);
-}
-
 /**
  * security_add_hooks - Add a modules hooks to the hook lists.
  * @hooks: the hooks to add
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e8da99550b67..71a10fedecb3 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7133,16 +7133,6 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = {
 
 static __init int selinux_init(void)
 {
-	if (!security_module_enable("selinux")) {
-		selinux_enabled = 0;
-		return 0;
-	}
-
-	if (!selinux_enabled) {
-		pr_info("SELinux:  Disabled at boot.\n");
-		return 0;
-	}
-
 	pr_info("SELinux:  Initializing.\n");
 
 	memset(&selinux_state, 0, sizeof(selinux_state));
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index db8bc6b6d8b0..f243044d5a55 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4834,9 +4834,6 @@ static __init int smack_init(void)
 	struct cred *cred;
 	struct task_smack *tsp;
 
-	if (!security_module_enable("smack"))
-		return 0;
-
 	smack_inode_cache = KMEM_CACHE(inode_smack, 0);
 	if (!smack_inode_cache)
 		return -ENOMEM;
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 09f7af130d3a..a46f6bc1e97c 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -540,8 +540,6 @@ static int __init tomoyo_init(void)
 {
 	struct cred *cred = (struct cred *) current_cred();
 
-	if (!security_module_enable("tomoyo"))
-		return 0;
 	/* register ourselves with the security framework */
 	security_add_hooks(tomoyo_hooks, ARRAY_SIZE(tomoyo_hooks), "tomoyo");
 	printk(KERN_INFO "TOMOYO Linux initialized\n");
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 16/32] LSM: Prepare for arbitrary LSM enabling
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (15 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 15/32] LSM: Lift LSM selection out of individual LSMs Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 17/32] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
                   ` (15 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Before now, all the LSMs that did not specify an "enable" variable in their
struct lsm_info were considered enabled by default. This prepares to make
LSM enabling more explicit. For all LSMs without an explicit "enable"
variable, a hard-coded storage location is chosen, and all LSMs without
an external "enable" state have their state explicitly set to "enabled".

This code appears more complex than it needs to be (comma-separated
list parsing and "set" function parameter) because its use will be
expanded on in the following patches to provide more explicit enabling.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 69 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git a/security/security.c b/security/security.c
index 4e5e67b82b7b..9459b4ee4fd9 100644
--- a/security/security.c
+++ b/security/security.c
@@ -54,17 +54,46 @@ static __initdata bool debug;
 
 static bool __init is_enabled(struct lsm_info *lsm)
 {
-	if (!lsm->enabled || *lsm->enabled)
-		return true;
+	if (WARN_ON(!lsm->enabled))
+		return false;
 
-	return false;
+	return *lsm->enabled;
 }
 
 /* Mark an LSM's enabled flag, if it exists. */
-static void __init set_enabled(struct lsm_info *lsm, bool enabled)
+static int lsm_enabled_true __initdata = 1;
+static int lsm_enabled_false __initdata = 0;
+
+static void __init default_enabled(struct lsm_info *lsm, bool enabled)
 {
+	/* If storage location already set, skip this one. */
 	if (lsm->enabled)
+		return;
+
+	/*
+	 * When an LSM hasn't configured an enable variable, we can use
+	 * a hard-coded location for storing the default enabled state.
+	 */
+	if (enabled)
+		lsm->enabled = &lsm_enabled_true;
+	else
+		lsm->enabled = &lsm_enabled_false;
+}
+
+static void __init set_enabled(struct lsm_info *lsm, bool enabled)
+{
+	if (WARN_ON(!lsm->enabled))
+		return;
+
+	if (lsm->enabled == &lsm_enabled_true) {
+		if (!enabled)
+			lsm->enabled = &lsm_enabled_false;
+	} else if (lsm->enabled == &lsm_enabled_false) {
+		if (enabled)
+			lsm->enabled = &lsm_enabled_true;
+	} else {
 		*lsm->enabled = enabled;
+	}
 }
 
 /* Is an LSM allowed to be initialized? */
@@ -127,6 +156,35 @@ static void __init major_lsm_init(void)
 	}
 }
 
+static void __init parse_lsm_enable(const char *str,
+				    void (*set)(struct lsm_info *, bool),
+				    bool enabled)
+{
+	char *sep, *name, *next;
+
+	if (!str)
+		return;
+
+	sep = kstrdup(str, GFP_KERNEL);
+	next = sep;
+	while ((name = strsep(&next, ",")) != NULL) {
+		struct lsm_info *lsm;
+
+		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+			if (strcmp(name, "all") == 0 ||
+			    strcmp(name, lsm->name) == 0)
+				set(lsm, enabled);
+		}
+	}
+	kfree(sep);
+}
+
+static void __init prepare_lsm_enable(void)
+{
+	/* Prepare defaults. */
+	parse_lsm_enable("all", default_enabled, true);
+}
+
 /**
  * security_init - initializes the security framework
  *
@@ -143,6 +201,9 @@ int __init security_init(void)
 	     i++)
 		INIT_HLIST_HEAD(&list[i]);
 
+	/* Figure out which LSMs are enabled and disabled. */
+	prepare_lsm_enable();
+
 	/*
 	 * Load minor LSMs, with the capability module always first.
 	 */
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 16/32] LSM: Prepare for arbitrary LSM enabling
  2018-10-02  0:54 ` [PATCH security-next v4 16/32] LSM: Prepare for arbitrary LSM enabling Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Before now, all the LSMs that did not specify an "enable" variable in their
struct lsm_info were considered enabled by default. This prepares to make
LSM enabling more explicit. For all LSMs without an explicit "enable"
variable, a hard-coded storage location is chosen, and all LSMs without
an external "enable" state have their state explicitly set to "enabled".

This code appears more complex than it needs to be (comma-separated
list parsing and "set" function parameter) because its use will be
expanded on in the following patches to provide more explicit enabling.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 69 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git a/security/security.c b/security/security.c
index 4e5e67b82b7b..9459b4ee4fd9 100644
--- a/security/security.c
+++ b/security/security.c
@@ -54,17 +54,46 @@ static __initdata bool debug;
 
 static bool __init is_enabled(struct lsm_info *lsm)
 {
-	if (!lsm->enabled || *lsm->enabled)
-		return true;
+	if (WARN_ON(!lsm->enabled))
+		return false;
 
-	return false;
+	return *lsm->enabled;
 }
 
 /* Mark an LSM's enabled flag, if it exists. */
-static void __init set_enabled(struct lsm_info *lsm, bool enabled)
+static int lsm_enabled_true __initdata = 1;
+static int lsm_enabled_false __initdata = 0;
+
+static void __init default_enabled(struct lsm_info *lsm, bool enabled)
 {
+	/* If storage location already set, skip this one. */
 	if (lsm->enabled)
+		return;
+
+	/*
+	 * When an LSM hasn't configured an enable variable, we can use
+	 * a hard-coded location for storing the default enabled state.
+	 */
+	if (enabled)
+		lsm->enabled = &lsm_enabled_true;
+	else
+		lsm->enabled = &lsm_enabled_false;
+}
+
+static void __init set_enabled(struct lsm_info *lsm, bool enabled)
+{
+	if (WARN_ON(!lsm->enabled))
+		return;
+
+	if (lsm->enabled == &lsm_enabled_true) {
+		if (!enabled)
+			lsm->enabled = &lsm_enabled_false;
+	} else if (lsm->enabled == &lsm_enabled_false) {
+		if (enabled)
+			lsm->enabled = &lsm_enabled_true;
+	} else {
 		*lsm->enabled = enabled;
+	}
 }
 
 /* Is an LSM allowed to be initialized? */
@@ -127,6 +156,35 @@ static void __init major_lsm_init(void)
 	}
 }
 
+static void __init parse_lsm_enable(const char *str,
+				    void (*set)(struct lsm_info *, bool),
+				    bool enabled)
+{
+	char *sep, *name, *next;
+
+	if (!str)
+		return;
+
+	sep = kstrdup(str, GFP_KERNEL);
+	next = sep;
+	while ((name = strsep(&next, ",")) != NULL) {
+		struct lsm_info *lsm;
+
+		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+			if (strcmp(name, "all") == 0 ||
+			    strcmp(name, lsm->name) == 0)
+				set(lsm, enabled);
+		}
+	}
+	kfree(sep);
+}
+
+static void __init prepare_lsm_enable(void)
+{
+	/* Prepare defaults. */
+	parse_lsm_enable("all", default_enabled, true);
+}
+
 /**
  * security_init - initializes the security framework
  *
@@ -143,6 +201,9 @@ int __init security_init(void)
 	     i++)
 		INIT_HLIST_HEAD(&list[i]);
 
+	/* Figure out which LSMs are enabled and disabled. */
+	prepare_lsm_enable();
+
 	/*
 	 * Load minor LSMs, with the capability module always first.
 	 */
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 17/32] LSM: Introduce CONFIG_LSM_ENABLE
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (16 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 16/32] LSM: Prepare for arbitrary LSM enabling Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 18/32] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
                   ` (14 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

To provide a set of default-enabled LSMs at boot, this introduces the
new CONFIG_LSM_ENABLE. A value of "all" means all builtin LSMs are
enabled by default. Any unlisted LSMs will be implicitly disabled
(excepting those with LSM-specific CONFIGs for enabling/disabling).

The behavior of the LSM-specific CONFIGs for SELinux are AppArmor
unchanged: the default-enabled state for those LSMs remains controlled
through their LSM-specific "enable" CONFIGs.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h | 2 +-
 security/Kconfig          | 8 ++++++++
 security/security.c       | 4 +++-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 9ecb623fb39d..fd85637a1931 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2044,7 +2044,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 struct lsm_info {
 	const char *name;	/* Required. */
 	unsigned long flags;	/* Optional: flags describing LSM */
-	int *enabled;		/* Optional: NULL means enabled. */
+	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/Kconfig b/security/Kconfig
index 27d8b2688f75..ac23feba584d 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -276,5 +276,13 @@ config DEFAULT_SECURITY
 	default "apparmor" if DEFAULT_SECURITY_APPARMOR
 	default "" if DEFAULT_SECURITY_DAC
 
+config LSM_ENABLE
+	string "LSMs to enable at boot time"
+	default "all"
+	help
+	  A comma-separated list of LSMs to enable by default at boot. The
+	  default is "all", to enable all LSM modules at boot. Any LSMs
+	  not listed here will be disabled by default.
+
 endmenu
 
diff --git a/security/security.c b/security/security.c
index 9459b4ee4fd9..35601000176b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -45,6 +45,8 @@ char *lsm_names;
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
 
+static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
+
 static __initdata bool debug;
 #define init_debug(...)						\
 	do {							\
@@ -182,7 +184,7 @@ static void __init parse_lsm_enable(const char *str,
 static void __init prepare_lsm_enable(void)
 {
 	/* Prepare defaults. */
-	parse_lsm_enable("all", default_enabled, true);
+	parse_lsm_enable(builtin_lsm_enable, default_enabled, true);
 }
 
 /**
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 17/32] LSM: Introduce CONFIG_LSM_ENABLE
  2018-10-02  0:54 ` [PATCH security-next v4 17/32] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

To provide a set of default-enabled LSMs at boot, this introduces the
new CONFIG_LSM_ENABLE. A value of "all" means all builtin LSMs are
enabled by default. Any unlisted LSMs will be implicitly disabled
(excepting those with LSM-specific CONFIGs for enabling/disabling).

The behavior of the LSM-specific CONFIGs for SELinux are AppArmor
unchanged: the default-enabled state for those LSMs remains controlled
through their LSM-specific "enable" CONFIGs.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h | 2 +-
 security/Kconfig          | 8 ++++++++
 security/security.c       | 4 +++-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 9ecb623fb39d..fd85637a1931 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2044,7 +2044,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 struct lsm_info {
 	const char *name;	/* Required. */
 	unsigned long flags;	/* Optional: flags describing LSM */
-	int *enabled;		/* Optional: NULL means enabled. */
+	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/Kconfig b/security/Kconfig
index 27d8b2688f75..ac23feba584d 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -276,5 +276,13 @@ config DEFAULT_SECURITY
 	default "apparmor" if DEFAULT_SECURITY_APPARMOR
 	default "" if DEFAULT_SECURITY_DAC
 
+config LSM_ENABLE
+	string "LSMs to enable at boot time"
+	default "all"
+	help
+	  A comma-separated list of LSMs to enable by default at boot. The
+	  default is "all", to enable all LSM modules at boot. Any LSMs
+	  not listed here will be disabled by default.
+
 endmenu
 
diff --git a/security/security.c b/security/security.c
index 9459b4ee4fd9..35601000176b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -45,6 +45,8 @@ char *lsm_names;
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
 
+static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
+
 static __initdata bool debug;
 #define init_debug(...)						\
 	do {							\
@@ -182,7 +184,7 @@ static void __init parse_lsm_enable(const char *str,
 static void __init prepare_lsm_enable(void)
 {
 	/* Prepare defaults. */
-	parse_lsm_enable("all", default_enabled, true);
+	parse_lsm_enable(builtin_lsm_enable, default_enabled, true);
 }
 
 /**
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 18/32] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (17 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 17/32] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 19/32] LSM: Prepare for reorganizing "security=" logic Kees Cook
                   ` (13 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This introduces the "lsm.enable=..." and "lsm.disable=..." boot parameters
which each can contain a comma-separated list of LSMs to enable or
disable, respectively. The string "all" matches all LSMs.

This has very similar functionality to the existing per-LSM enable
handling ("apparmor.enabled=...", etc), but provides a centralized
place to perform the changes. These parameters take precedent over any
LSM-specific boot parameters.

Disabling an LSM means it will not be considered when performing
initializations. Enabling an LSM means either undoing a previous
LSM-specific boot parameter disabling or a undoing a default-disabled
CONFIG setting.

For example: "lsm.disable=apparmor apparmor.enabled=1" will result in
AppArmor being disabled. "selinux.enabled=0 lsm.enable=selinux" will
result in SELinux being enabled.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 .../admin-guide/kernel-parameters.txt         | 12 ++++++++++
 security/Kconfig                              |  4 +++-
 security/security.c                           | 22 +++++++++++++++++++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 32d323ee9218..67c90985d2b8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2276,6 +2276,18 @@
 
 	lsm.debug	[SECURITY] Enable LSM initialization debugging output.
 
+	lsm.disable=lsm1,...,lsmN
+			[SECURITY] Comma-separated list of LSMs to disable
+			at boot time. This overrides "lsm.enable=",
+			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and boot
+			parameters.
+
+	lsm.enable=lsm1,...,lsmN
+			[SECURITY] Comma-separated list of LSMs to enable
+			at boot time. This overrides any omissions from
+			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
+			boot parameters.
+
 	machvec=	[IA-64] Force the use of a particular machine-vector
 			(machvec) in a generic kernel.
 			Example: machvec=hpzx1_swiotlb
diff --git a/security/Kconfig b/security/Kconfig
index ac23feba584d..1e57619fd561 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -282,7 +282,9 @@ config LSM_ENABLE
 	help
 	  A comma-separated list of LSMs to enable by default at boot. The
 	  default is "all", to enable all LSM modules at boot. Any LSMs
-	  not listed here will be disabled by default.
+	  not listed here will be disabled by default. This can be
+	  changed with the "lsm.enable=" and "lsm.disable=" boot
+	  parameters.
 
 endmenu
 
diff --git a/security/security.c b/security/security.c
index 35601000176b..3fff2d1d1ec4 100644
--- a/security/security.c
+++ b/security/security.c
@@ -44,6 +44,8 @@ char *lsm_names;
 /* Boot-time LSM user choice */
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
+static __initdata const char *chosen_lsm_enable;
+static __initdata const char *chosen_lsm_disable;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
 
@@ -185,6 +187,10 @@ static void __init prepare_lsm_enable(void)
 {
 	/* Prepare defaults. */
 	parse_lsm_enable(builtin_lsm_enable, default_enabled, true);
+
+	/* Process "lsm.enable=" and "lsm.disable=", if given. */
+	parse_lsm_enable(chosen_lsm_enable, set_enabled, true);
+	parse_lsm_enable(chosen_lsm_disable, set_enabled, false);
 }
 
 /**
@@ -240,6 +246,22 @@ static int __init enable_debug(char *str)
 }
 __setup("lsm.debug", enable_debug);
 
+/* Explicitly enable a list of LSMs. */
+static int __init enable_lsm(char *str)
+{
+	chosen_lsm_enable = str;
+	return 1;
+}
+__setup("lsm.enable=", enable_lsm);
+
+/* Explicitly disable a list of LSMs. */
+static int __init disable_lsm(char *str)
+{
+	chosen_lsm_disable = str;
+	return 1;
+}
+__setup("lsm.disable=", disable_lsm);
+
 static bool match_last_lsm(const char *list, const char *lsm)
 {
 	const char *last;
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 18/32] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-02  0:54 ` [PATCH security-next v4 18/32] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This introduces the "lsm.enable=..." and "lsm.disable=..." boot parameters
which each can contain a comma-separated list of LSMs to enable or
disable, respectively. The string "all" matches all LSMs.

This has very similar functionality to the existing per-LSM enable
handling ("apparmor.enabled=...", etc), but provides a centralized
place to perform the changes. These parameters take precedent over any
LSM-specific boot parameters.

Disabling an LSM means it will not be considered when performing
initializations. Enabling an LSM means either undoing a previous
LSM-specific boot parameter disabling or a undoing a default-disabled
CONFIG setting.

For example: "lsm.disable=apparmor apparmor.enabled=1" will result in
AppArmor being disabled. "selinux.enabled=0 lsm.enable=selinux" will
result in SELinux being enabled.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 .../admin-guide/kernel-parameters.txt         | 12 ++++++++++
 security/Kconfig                              |  4 +++-
 security/security.c                           | 22 +++++++++++++++++++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 32d323ee9218..67c90985d2b8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2276,6 +2276,18 @@
 
 	lsm.debug	[SECURITY] Enable LSM initialization debugging output.
 
+	lsm.disable=lsm1,...,lsmN
+			[SECURITY] Comma-separated list of LSMs to disable
+			at boot time. This overrides "lsm.enable=",
+			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and boot
+			parameters.
+
+	lsm.enable=lsm1,...,lsmN
+			[SECURITY] Comma-separated list of LSMs to enable
+			at boot time. This overrides any omissions from
+			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
+			boot parameters.
+
 	machvec=	[IA-64] Force the use of a particular machine-vector
 			(machvec) in a generic kernel.
 			Example: machvec=hpzx1_swiotlb
diff --git a/security/Kconfig b/security/Kconfig
index ac23feba584d..1e57619fd561 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -282,7 +282,9 @@ config LSM_ENABLE
 	help
 	  A comma-separated list of LSMs to enable by default at boot. The
 	  default is "all", to enable all LSM modules at boot. Any LSMs
-	  not listed here will be disabled by default.
+	  not listed here will be disabled by default. This can be
+	  changed with the "lsm.enable=" and "lsm.disable=" boot
+	  parameters.
 
 endmenu
 
diff --git a/security/security.c b/security/security.c
index 35601000176b..3fff2d1d1ec4 100644
--- a/security/security.c
+++ b/security/security.c
@@ -44,6 +44,8 @@ char *lsm_names;
 /* Boot-time LSM user choice */
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
+static __initdata const char *chosen_lsm_enable;
+static __initdata const char *chosen_lsm_disable;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
 
@@ -185,6 +187,10 @@ static void __init prepare_lsm_enable(void)
 {
 	/* Prepare defaults. */
 	parse_lsm_enable(builtin_lsm_enable, default_enabled, true);
+
+	/* Process "lsm.enable=" and "lsm.disable=", if given. */
+	parse_lsm_enable(chosen_lsm_enable, set_enabled, true);
+	parse_lsm_enable(chosen_lsm_disable, set_enabled, false);
 }
 
 /**
@@ -240,6 +246,22 @@ static int __init enable_debug(char *str)
 }
 __setup("lsm.debug", enable_debug);
 
+/* Explicitly enable a list of LSMs. */
+static int __init enable_lsm(char *str)
+{
+	chosen_lsm_enable = str;
+	return 1;
+}
+__setup("lsm.enable=", enable_lsm);
+
+/* Explicitly disable a list of LSMs. */
+static int __init disable_lsm(char *str)
+{
+	chosen_lsm_disable = str;
+	return 1;
+}
+__setup("lsm.disable=", disable_lsm);
+
 static bool match_last_lsm(const char *list, const char *lsm)
 {
 	const char *last;
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 19/32] LSM: Prepare for reorganizing "security=" logic
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (18 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 18/32] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 20/32] LSM: Refactor "security=" in terms of enable/disable Kees Cook
                   ` (12 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This moves the string handling for "security=" boot parameter into
a stored pointer instead of a string duplicate. This will allow
easier handling of the string when switching logic to use the coming
enable/disable infrastructure.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/security/security.c b/security/security.c
index 3fff2d1d1ec4..455ba2767965 100644
--- a/security/security.c
+++ b/security/security.c
@@ -34,18 +34,14 @@
 
 #define MAX_LSM_EVM_XATTR	2
 
-/* Maximum number of letters for an LSM name string */
-#define SECURITY_NAME_MAX	10
-
 struct security_hook_heads security_hook_heads __lsm_ro_after_init;
 static ATOMIC_NOTIFIER_HEAD(lsm_notifier_chain);
 
 char *lsm_names;
 /* Boot-time LSM user choice */
-static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
-	CONFIG_DEFAULT_SECURITY;
 static __initdata const char *chosen_lsm_enable;
 static __initdata const char *chosen_lsm_disable;
+static __initdata const char *chosen_major_lsm;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
 
@@ -112,7 +108,7 @@ static bool __init lsm_allowed(struct lsm_info *lsm)
 		return true;
 
 	/* Disabled if this LSM isn't the chosen one. */
-	if (strcmp(lsm->name, chosen_lsm) != 0)
+	if (strcmp(lsm->name, chosen_major_lsm) != 0)
 		return false;
 
 	return true;
@@ -191,6 +187,9 @@ static void __init prepare_lsm_enable(void)
 	/* Process "lsm.enable=" and "lsm.disable=", if given. */
 	parse_lsm_enable(chosen_lsm_enable, set_enabled, true);
 	parse_lsm_enable(chosen_lsm_disable, set_enabled, false);
+
+	if (!chosen_major_lsm)
+		chosen_major_lsm = CONFIG_DEFAULT_SECURITY;
 }
 
 /**
@@ -231,12 +230,12 @@ int __init security_init(void)
 }
 
 /* Save user chosen LSM */
-static int __init choose_lsm(char *str)
+static int __init choose_major_lsm(char *str)
 {
-	strncpy(chosen_lsm, str, SECURITY_NAME_MAX);
+	chosen_major_lsm = str;
 	return 1;
 }
-__setup("security=", choose_lsm);
+__setup("security=", choose_major_lsm);
 
 /* Enable LSM order debugging. */
 static int __init enable_debug(char *str)
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 19/32] LSM: Prepare for reorganizing "security=" logic
  2018-10-02  0:54 ` [PATCH security-next v4 19/32] LSM: Prepare for reorganizing "security=" logic Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This moves the string handling for "security=" boot parameter into
a stored pointer instead of a string duplicate. This will allow
easier handling of the string when switching logic to use the coming
enable/disable infrastructure.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
---
 security/security.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/security/security.c b/security/security.c
index 3fff2d1d1ec4..455ba2767965 100644
--- a/security/security.c
+++ b/security/security.c
@@ -34,18 +34,14 @@
 
 #define MAX_LSM_EVM_XATTR	2
 
-/* Maximum number of letters for an LSM name string */
-#define SECURITY_NAME_MAX	10
-
 struct security_hook_heads security_hook_heads __lsm_ro_after_init;
 static ATOMIC_NOTIFIER_HEAD(lsm_notifier_chain);
 
 char *lsm_names;
 /* Boot-time LSM user choice */
-static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
-	CONFIG_DEFAULT_SECURITY;
 static __initdata const char *chosen_lsm_enable;
 static __initdata const char *chosen_lsm_disable;
+static __initdata const char *chosen_major_lsm;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
 
@@ -112,7 +108,7 @@ static bool __init lsm_allowed(struct lsm_info *lsm)
 		return true;
 
 	/* Disabled if this LSM isn't the chosen one. */
-	if (strcmp(lsm->name, chosen_lsm) != 0)
+	if (strcmp(lsm->name, chosen_major_lsm) != 0)
 		return false;
 
 	return true;
@@ -191,6 +187,9 @@ static void __init prepare_lsm_enable(void)
 	/* Process "lsm.enable=" and "lsm.disable=", if given. */
 	parse_lsm_enable(chosen_lsm_enable, set_enabled, true);
 	parse_lsm_enable(chosen_lsm_disable, set_enabled, false);
+
+	if (!chosen_major_lsm)
+		chosen_major_lsm = CONFIG_DEFAULT_SECURITY;
 }
 
 /**
@@ -231,12 +230,12 @@ int __init security_init(void)
 }
 
 /* Save user chosen LSM */
-static int __init choose_lsm(char *str)
+static int __init choose_major_lsm(char *str)
 {
-	strncpy(chosen_lsm, str, SECURITY_NAME_MAX);
+	chosen_major_lsm = str;
 	return 1;
 }
-__setup("security=", choose_lsm);
+__setup("security=", choose_major_lsm);
 
 /* Enable LSM order debugging. */
 static int __init enable_debug(char *str)
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 20/32] LSM: Refactor "security=" in terms of enable/disable
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (19 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 19/32] LSM: Prepare for reorganizing "security=" logic Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic Kees Cook
                   ` (11 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

For what are marked as the Legacy Major LSMs, make them effectively
exclusive when selected on the "security=" boot parameter, to handle
the future case of when a previously major LSMs become non-exclusive
(e.g. when TOMOYO starts blob-sharing).

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/security.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/security/security.c b/security/security.c
index 455ba2767965..d7132c181ea6 100644
--- a/security/security.c
+++ b/security/security.c
@@ -103,14 +103,6 @@ static bool __init lsm_allowed(struct lsm_info *lsm)
 	if (!is_enabled(lsm))
 		return false;
 
-	/* Skip major-specific checks if not a major LSM. */
-	if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
-		return true;
-
-	/* Disabled if this LSM isn't the chosen one. */
-	if (strcmp(lsm->name, chosen_major_lsm) != 0)
-		return false;
-
 	return true;
 }
 
@@ -188,8 +180,24 @@ static void __init prepare_lsm_enable(void)
 	parse_lsm_enable(chosen_lsm_enable, set_enabled, true);
 	parse_lsm_enable(chosen_lsm_disable, set_enabled, false);
 
+	/* Process "security=", if given. */
 	if (!chosen_major_lsm)
 		chosen_major_lsm = CONFIG_DEFAULT_SECURITY;
+	if (chosen_major_lsm) {
+		struct lsm_info *lsm;
+
+		/*
+		 * To match the original "security=" behavior, this
+		 * explicitly does NOT fallback to another Legacy Major
+		 * if the selected one was separately disabled: disable
+		 * all non-matching Legacy Major LSMs.
+		 */
+		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+			if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) &&
+			    strcmp(lsm->name, chosen_major_lsm) != 0)
+				set_enabled(lsm, false);
+		}
+	}
 }
 
 /**
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 20/32] LSM: Refactor "security=" in terms of enable/disable
  2018-10-02  0:54 ` [PATCH security-next v4 20/32] LSM: Refactor "security=" in terms of enable/disable Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

For what are marked as the Legacy Major LSMs, make them effectively
exclusive when selected on the "security=" boot parameter, to handle
the future case of when a previously major LSMs become non-exclusive
(e.g. when TOMOYO starts blob-sharing).

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/security.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/security/security.c b/security/security.c
index 455ba2767965..d7132c181ea6 100644
--- a/security/security.c
+++ b/security/security.c
@@ -103,14 +103,6 @@ static bool __init lsm_allowed(struct lsm_info *lsm)
 	if (!is_enabled(lsm))
 		return false;
 
-	/* Skip major-specific checks if not a major LSM. */
-	if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
-		return true;
-
-	/* Disabled if this LSM isn't the chosen one. */
-	if (strcmp(lsm->name, chosen_major_lsm) != 0)
-		return false;
-
 	return true;
 }
 
@@ -188,8 +180,24 @@ static void __init prepare_lsm_enable(void)
 	parse_lsm_enable(chosen_lsm_enable, set_enabled, true);
 	parse_lsm_enable(chosen_lsm_disable, set_enabled, false);
 
+	/* Process "security=", if given. */
 	if (!chosen_major_lsm)
 		chosen_major_lsm = CONFIG_DEFAULT_SECURITY;
+	if (chosen_major_lsm) {
+		struct lsm_info *lsm;
+
+		/*
+		 * To match the original "security=" behavior, this
+		 * explicitly does NOT fallback to another Legacy Major
+		 * if the selected one was separately disabled: disable
+		 * all non-matching Legacy Major LSMs.
+		 */
+		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+			if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) &&
+			    strcmp(lsm->name, chosen_major_lsm) != 0)
+				set_enabled(lsm, false);
+		}
+	}
 }
 
 /**
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (20 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 20/32] LSM: Refactor "security=" in terms of enable/disable Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  1:18   ` Randy Dunlap
  2018-10-02  0:54 ` [PATCH security-next v4 22/32] apparmor: Remove boot parameter Kees Cook
                   ` (10 subsequent siblings)
  32 siblings, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Prior to this patch, default "enable" behavior was unchanged: SELinux
and AppArmor were controlled separately from the centralized control
defined by CONFIG_LSM_ENABLE and "lsm.enable=...". This changes the
logic to give all control over to the central logic.

Instead of allowing SELinux and AppArmor to override the central LSM
enabling logic, by having separate CONFIG and boot parameters, this
forces all "enable" variables to disabled, then enables any listed in
the CONFIG_LSM_ENABLE and "lsm.enable=..." settings, and finally disables
any listed in "lsm.disable=...".

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 .../admin-guide/kernel-parameters.txt         |  6 ++--
 include/linux/lsm_hooks.h                     |  2 +-
 security/security.c                           | 32 +++++++------------
 3 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 67c90985d2b8..f646cfab5613 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2279,14 +2279,12 @@
 	lsm.disable=lsm1,...,lsmN
 			[SECURITY] Comma-separated list of LSMs to disable
 			at boot time. This overrides "lsm.enable=",
-			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and boot
-			parameters.
+			CONFIG_LSM_ENABLE.
 
 	lsm.enable=lsm1,...,lsmN
 			[SECURITY] Comma-separated list of LSMs to enable
 			at boot time. This overrides any omissions from
-			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
-			boot parameters.
+			CONFIG_LSM_ENABLE.
 
 	machvec=	[IA-64] Force the use of a particular machine-vector
 			(machvec) in a generic kernel.
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index fd85637a1931..b026ea93ff01 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2044,7 +2044,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 struct lsm_info {
 	const char *name;	/* Required. */
 	unsigned long flags;	/* Optional: flags describing LSM */
-	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
+	int *enabled;		/* Optional: set based on CONFIG_LSM_ENABLE */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/security.c b/security/security.c
index d7132c181ea6..40b9f508b856 100644
--- a/security/security.c
+++ b/security/security.c
@@ -63,27 +63,19 @@ static bool __init is_enabled(struct lsm_info *lsm)
 /* Mark an LSM's enabled flag, if it exists. */
 static int lsm_enabled_true __initdata = 1;
 static int lsm_enabled_false __initdata = 0;
-
-static void __init default_enabled(struct lsm_info *lsm, bool enabled)
+static void __init set_enabled(struct lsm_info *lsm, bool enabled)
 {
-	/* If storage location already set, skip this one. */
-	if (lsm->enabled)
-		return;
-
 	/*
 	 * When an LSM hasn't configured an enable variable, we can use
 	 * a hard-coded location for storing the default enabled state.
 	 */
-	if (enabled)
-		lsm->enabled = &lsm_enabled_true;
-	else
-		lsm->enabled = &lsm_enabled_false;
-}
-
-static void __init set_enabled(struct lsm_info *lsm, bool enabled)
-{
-	if (WARN_ON(!lsm->enabled))
+	if (!lsm->enabled) {
+		if (enabled)
+			lsm->enabled = &lsm_enabled_true;
+		else
+			lsm->enabled = &lsm_enabled_false;
 		return;
+	}
 
 	if (lsm->enabled == &lsm_enabled_true) {
 		if (!enabled)
@@ -149,7 +141,6 @@ static void __init major_lsm_init(void)
 }
 
 static void __init parse_lsm_enable(const char *str,
-				    void (*set)(struct lsm_info *, bool),
 				    bool enabled)
 {
 	char *sep, *name, *next;
@@ -165,7 +156,7 @@ static void __init parse_lsm_enable(const char *str,
 		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
 			if (strcmp(name, "all") == 0 ||
 			    strcmp(name, lsm->name) == 0)
-				set(lsm, enabled);
+				set_enabled(lsm, enabled);
 		}
 	}
 	kfree(sep);
@@ -174,11 +165,12 @@ static void __init parse_lsm_enable(const char *str,
 static void __init prepare_lsm_enable(void)
 {
 	/* Prepare defaults. */
-	parse_lsm_enable(builtin_lsm_enable, default_enabled, true);
+	parse_lsm_enable("all", false);
+	parse_lsm_enable(builtin_lsm_enable, true);
 
 	/* Process "lsm.enable=" and "lsm.disable=", if given. */
-	parse_lsm_enable(chosen_lsm_enable, set_enabled, true);
-	parse_lsm_enable(chosen_lsm_disable, set_enabled, false);
+	parse_lsm_enable(chosen_lsm_enable, true);
+	parse_lsm_enable(chosen_lsm_disable, false);
 
 	/* Process "security=", if given. */
 	if (!chosen_major_lsm)
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic
  2018-10-02  0:54 ` [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  2018-10-02  1:18   ` Randy Dunlap
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Prior to this patch, default "enable" behavior was unchanged: SELinux
and AppArmor were controlled separately from the centralized control
defined by CONFIG_LSM_ENABLE and "lsm.enable=...". This changes the
logic to give all control over to the central logic.

Instead of allowing SELinux and AppArmor to override the central LSM
enabling logic, by having separate CONFIG and boot parameters, this
forces all "enable" variables to disabled, then enables any listed in
the CONFIG_LSM_ENABLE and "lsm.enable=..." settings, and finally disables
any listed in "lsm.disable=...".

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 .../admin-guide/kernel-parameters.txt         |  6 ++--
 include/linux/lsm_hooks.h                     |  2 +-
 security/security.c                           | 32 +++++++------------
 3 files changed, 15 insertions(+), 25 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 67c90985d2b8..f646cfab5613 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2279,14 +2279,12 @@
 	lsm.disable=lsm1,...,lsmN
 			[SECURITY] Comma-separated list of LSMs to disable
 			at boot time. This overrides "lsm.enable=",
-			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and boot
-			parameters.
+			CONFIG_LSM_ENABLE.
 
 	lsm.enable=lsm1,...,lsmN
 			[SECURITY] Comma-separated list of LSMs to enable
 			at boot time. This overrides any omissions from
-			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
-			boot parameters.
+			CONFIG_LSM_ENABLE.
 
 	machvec=	[IA-64] Force the use of a particular machine-vector
 			(machvec) in a generic kernel.
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index fd85637a1931..b026ea93ff01 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2044,7 +2044,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 struct lsm_info {
 	const char *name;	/* Required. */
 	unsigned long flags;	/* Optional: flags describing LSM */
-	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
+	int *enabled;		/* Optional: set based on CONFIG_LSM_ENABLE */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/security.c b/security/security.c
index d7132c181ea6..40b9f508b856 100644
--- a/security/security.c
+++ b/security/security.c
@@ -63,27 +63,19 @@ static bool __init is_enabled(struct lsm_info *lsm)
 /* Mark an LSM's enabled flag, if it exists. */
 static int lsm_enabled_true __initdata = 1;
 static int lsm_enabled_false __initdata = 0;
-
-static void __init default_enabled(struct lsm_info *lsm, bool enabled)
+static void __init set_enabled(struct lsm_info *lsm, bool enabled)
 {
-	/* If storage location already set, skip this one. */
-	if (lsm->enabled)
-		return;
-
 	/*
 	 * When an LSM hasn't configured an enable variable, we can use
 	 * a hard-coded location for storing the default enabled state.
 	 */
-	if (enabled)
-		lsm->enabled = &lsm_enabled_true;
-	else
-		lsm->enabled = &lsm_enabled_false;
-}
-
-static void __init set_enabled(struct lsm_info *lsm, bool enabled)
-{
-	if (WARN_ON(!lsm->enabled))
+	if (!lsm->enabled) {
+		if (enabled)
+			lsm->enabled = &lsm_enabled_true;
+		else
+			lsm->enabled = &lsm_enabled_false;
 		return;
+	}
 
 	if (lsm->enabled == &lsm_enabled_true) {
 		if (!enabled)
@@ -149,7 +141,6 @@ static void __init major_lsm_init(void)
 }
 
 static void __init parse_lsm_enable(const char *str,
-				    void (*set)(struct lsm_info *, bool),
 				    bool enabled)
 {
 	char *sep, *name, *next;
@@ -165,7 +156,7 @@ static void __init parse_lsm_enable(const char *str,
 		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
 			if (strcmp(name, "all") == 0 ||
 			    strcmp(name, lsm->name) == 0)
-				set(lsm, enabled);
+				set_enabled(lsm, enabled);
 		}
 	}
 	kfree(sep);
@@ -174,11 +165,12 @@ static void __init parse_lsm_enable(const char *str,
 static void __init prepare_lsm_enable(void)
 {
 	/* Prepare defaults. */
-	parse_lsm_enable(builtin_lsm_enable, default_enabled, true);
+	parse_lsm_enable("all", false);
+	parse_lsm_enable(builtin_lsm_enable, true);
 
 	/* Process "lsm.enable=" and "lsm.disable=", if given. */
-	parse_lsm_enable(chosen_lsm_enable, set_enabled, true);
-	parse_lsm_enable(chosen_lsm_disable, set_enabled, false);
+	parse_lsm_enable(chosen_lsm_enable, true);
+	parse_lsm_enable(chosen_lsm_disable, false);
 
 	/* Process "security=", if given. */
 	if (!chosen_major_lsm)
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 22/32] apparmor: Remove boot parameter
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (21 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 23/32] selinux: " Kees Cook
                   ` (9 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-specific enabling logic from
AppArmor, though it leaves the existing userspace API visibility into
/sys/module/apparmor/parameters/enabled.

Co-developed-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  7 -------
 security/apparmor/Kconfig                       | 16 ----------------
 security/apparmor/lsm.c                         |  7 ++-----
 3 files changed, 2 insertions(+), 28 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f646cfab5613..cf963febebb0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4054,13 +4054,6 @@
 			If enabled at boot time, /selinux/disable can be used
 			later to disable prior to initial policy load.
 
-	apparmor=	[APPARMOR] Disable or enable AppArmor at boot time
-			Format: { "0" | "1" }
-			See security/apparmor/Kconfig help text
-			0 -- disable.
-			1 -- enable.
-			Default value is set via kernel config option.
-
 	serialnumber	[BUGS=X86-32]
 
 	shapers=	[NET]
diff --git a/security/apparmor/Kconfig b/security/apparmor/Kconfig
index b6b68a7750ce..3de21f46c82a 100644
--- a/security/apparmor/Kconfig
+++ b/security/apparmor/Kconfig
@@ -14,22 +14,6 @@ config SECURITY_APPARMOR
 
 	  If you are unsure how to answer this question, answer N.
 
-config SECURITY_APPARMOR_BOOTPARAM_VALUE
-	int "AppArmor boot parameter default value"
-	depends on SECURITY_APPARMOR
-	range 0 1
-	default 1
-	help
-	  This option sets the default value for the kernel parameter
-	  'apparmor', which allows AppArmor to be enabled or disabled
-          at boot.  If this option is set to 0 (zero), the AppArmor
-	  kernel parameter will default to 0, disabling AppArmor at
-	  boot.  If this option is set to 1 (one), the AppArmor
-	  kernel parameter will default to 1, enabling AppArmor at
-	  boot.
-
-	  If you are unsure how to answer this question, answer 1.
-
 config SECURITY_APPARMOR_HASH
 	bool "Enable introspection of sha1 hashes for loaded profiles"
 	depends on SECURITY_APPARMOR
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index bc56b058dc75..4cd96a66ed6f 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1303,15 +1303,12 @@ bool aa_g_paranoid_load = true;
 module_param_named(paranoid_load, aa_g_paranoid_load, aabool, S_IRUGO);
 
 /* Boot time disable flag */
-static int apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
+static int apparmor_enabled __lsm_ro_after_init;
 module_param_named(enabled, apparmor_enabled, int, 0444);
 
 static int __init apparmor_enabled_setup(char *str)
 {
-	unsigned long enabled;
-	int error = kstrtoul(str, 0, &enabled);
-	if (!error)
-		apparmor_enabled = enabled ? 1 : 0;
+	pr_err("Boot param 'apparmor=' ignored. Use 'lsm.disable=apparmor'\n");
 	return 1;
 }
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 22/32] apparmor: Remove boot parameter
  2018-10-02  0:54 ` [PATCH security-next v4 22/32] apparmor: Remove boot parameter Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-specific enabling logic from
AppArmor, though it leaves the existing userspace API visibility into
/sys/module/apparmor/parameters/enabled.

Co-developed-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  7 -------
 security/apparmor/Kconfig                       | 16 ----------------
 security/apparmor/lsm.c                         |  7 ++-----
 3 files changed, 2 insertions(+), 28 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f646cfab5613..cf963febebb0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4054,13 +4054,6 @@
 			If enabled at boot time, /selinux/disable can be used
 			later to disable prior to initial policy load.
 
-	apparmor=	[APPARMOR] Disable or enable AppArmor at boot time
-			Format: { "0" | "1" }
-			See security/apparmor/Kconfig help text
-			0 -- disable.
-			1 -- enable.
-			Default value is set via kernel config option.
-
 	serialnumber	[BUGS=X86-32]
 
 	shapers=	[NET]
diff --git a/security/apparmor/Kconfig b/security/apparmor/Kconfig
index b6b68a7750ce..3de21f46c82a 100644
--- a/security/apparmor/Kconfig
+++ b/security/apparmor/Kconfig
@@ -14,22 +14,6 @@ config SECURITY_APPARMOR
 
 	  If you are unsure how to answer this question, answer N.
 
-config SECURITY_APPARMOR_BOOTPARAM_VALUE
-	int "AppArmor boot parameter default value"
-	depends on SECURITY_APPARMOR
-	range 0 1
-	default 1
-	help
-	  This option sets the default value for the kernel parameter
-	  'apparmor', which allows AppArmor to be enabled or disabled
-          at boot.  If this option is set to 0 (zero), the AppArmor
-	  kernel parameter will default to 0, disabling AppArmor at
-	  boot.  If this option is set to 1 (one), the AppArmor
-	  kernel parameter will default to 1, enabling AppArmor at
-	  boot.
-
-	  If you are unsure how to answer this question, answer 1.
-
 config SECURITY_APPARMOR_HASH
 	bool "Enable introspection of sha1 hashes for loaded profiles"
 	depends on SECURITY_APPARMOR
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index bc56b058dc75..4cd96a66ed6f 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1303,15 +1303,12 @@ bool aa_g_paranoid_load = true;
 module_param_named(paranoid_load, aa_g_paranoid_load, aabool, S_IRUGO);
 
 /* Boot time disable flag */
-static int apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
+static int apparmor_enabled __lsm_ro_after_init;
 module_param_named(enabled, apparmor_enabled, int, 0444);
 
 static int __init apparmor_enabled_setup(char *str)
 {
-	unsigned long enabled;
-	int error = kstrtoul(str, 0, &enabled);
-	if (!error)
-		apparmor_enabled = enabled ? 1 : 0;
+	pr_err("Boot param 'apparmor=' ignored. Use 'lsm.disable=apparmor'\n");
 	return 1;
 }
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (22 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 22/32] apparmor: Remove boot parameter Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02 12:12   ` Paul Moore
  2018-10-02  0:54 ` [PATCH security-next v4 24/32] LSM: Build ordered list of ordered LSMs for init Kees Cook
                   ` (8 subsequent siblings)
  32 siblings, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-specific enabling logic from
SELinux.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 .../admin-guide/kernel-parameters.txt         |  9 ------
 security/selinux/Kconfig                      | 29 -------------------
 security/selinux/hooks.c                      | 15 +---------
 3 files changed, 1 insertion(+), 52 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index cf963febebb0..0d10ab3d020e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4045,15 +4045,6 @@
 			loaded. An invalid security module name will be treated
 			as if no module has been chosen.
 
-	selinux=	[SELINUX] Disable or enable SELinux at boot time.
-			Format: { "0" | "1" }
-			See security/selinux/Kconfig help text.
-			0 -- disable.
-			1 -- enable.
-			Default value is set via kernel config option.
-			If enabled at boot time, /selinux/disable can be used
-			later to disable prior to initial policy load.
-
 	serialnumber	[BUGS=X86-32]
 
 	shapers=	[NET]
diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
index 8af7a690eb40..86936528a0bb 100644
--- a/security/selinux/Kconfig
+++ b/security/selinux/Kconfig
@@ -8,35 +8,6 @@ config SECURITY_SELINUX
 	  You will also need a policy configuration and a labeled filesystem.
 	  If you are unsure how to answer this question, answer N.
 
-config SECURITY_SELINUX_BOOTPARAM
-	bool "NSA SELinux boot parameter"
-	depends on SECURITY_SELINUX
-	default n
-	help
-	  This option adds a kernel parameter 'selinux', which allows SELinux
-	  to be disabled at boot.  If this option is selected, SELinux
-	  functionality can be disabled with selinux=0 on the kernel
-	  command line.  The purpose of this option is to allow a single
-	  kernel image to be distributed with SELinux built in, but not
-	  necessarily enabled.
-
-	  If you are unsure how to answer this question, answer N.
-
-config SECURITY_SELINUX_BOOTPARAM_VALUE
-	int "NSA SELinux boot parameter default value"
-	depends on SECURITY_SELINUX_BOOTPARAM
-	range 0 1
-	default 1
-	help
-	  This option sets the default value for the kernel parameter
-	  'selinux', which allows SELinux to be disabled at boot.  If this
-	  option is set to 0 (zero), the SELinux kernel parameter will
-	  default to 0, disabling SELinux at bootup.  If this option is
-	  set to 1 (one), the SELinux kernel parameter will default to 1,
-	  enabling SELinux at bootup.
-
-	  If you are unsure how to answer this question, answer 1.
-
 config SECURITY_SELINUX_DISABLE
 	bool "NSA SELinux runtime disable"
 	depends on SECURITY_SELINUX
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 71a10fedecb3..8f5eea097612 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -120,20 +120,7 @@ __setup("enforcing=", enforcing_setup);
 #define selinux_enforcing_boot 1
 #endif
 
-#ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
-int selinux_enabled = CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE;
-
-static int __init selinux_enabled_setup(char *str)
-{
-	unsigned long enabled;
-	if (!kstrtoul(str, 0, &enabled))
-		selinux_enabled = enabled ? 1 : 0;
-	return 1;
-}
-__setup("selinux=", selinux_enabled_setup);
-#else
-int selinux_enabled = 1;
-#endif
+int selinux_enabled __lsm_ro_after_init;
 
 static unsigned int selinux_checkreqprot_boot =
 	CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE;
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02  0:54 ` [PATCH security-next v4 23/32] selinux: " Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  2018-10-02 12:12   ` Paul Moore
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
"lsm.enable=...", this removes the LSM-specific enabling logic from
SELinux.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 .../admin-guide/kernel-parameters.txt         |  9 ------
 security/selinux/Kconfig                      | 29 -------------------
 security/selinux/hooks.c                      | 15 +---------
 3 files changed, 1 insertion(+), 52 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index cf963febebb0..0d10ab3d020e 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4045,15 +4045,6 @@
 			loaded. An invalid security module name will be treated
 			as if no module has been chosen.
 
-	selinux=	[SELINUX] Disable or enable SELinux at boot time.
-			Format: { "0" | "1" }
-			See security/selinux/Kconfig help text.
-			0 -- disable.
-			1 -- enable.
-			Default value is set via kernel config option.
-			If enabled at boot time, /selinux/disable can be used
-			later to disable prior to initial policy load.
-
 	serialnumber	[BUGS=X86-32]
 
 	shapers=	[NET]
diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
index 8af7a690eb40..86936528a0bb 100644
--- a/security/selinux/Kconfig
+++ b/security/selinux/Kconfig
@@ -8,35 +8,6 @@ config SECURITY_SELINUX
 	  You will also need a policy configuration and a labeled filesystem.
 	  If you are unsure how to answer this question, answer N.
 
-config SECURITY_SELINUX_BOOTPARAM
-	bool "NSA SELinux boot parameter"
-	depends on SECURITY_SELINUX
-	default n
-	help
-	  This option adds a kernel parameter 'selinux', which allows SELinux
-	  to be disabled at boot.  If this option is selected, SELinux
-	  functionality can be disabled with selinux=0 on the kernel
-	  command line.  The purpose of this option is to allow a single
-	  kernel image to be distributed with SELinux built in, but not
-	  necessarily enabled.
-
-	  If you are unsure how to answer this question, answer N.
-
-config SECURITY_SELINUX_BOOTPARAM_VALUE
-	int "NSA SELinux boot parameter default value"
-	depends on SECURITY_SELINUX_BOOTPARAM
-	range 0 1
-	default 1
-	help
-	  This option sets the default value for the kernel parameter
-	  'selinux', which allows SELinux to be disabled at boot.  If this
-	  option is set to 0 (zero), the SELinux kernel parameter will
-	  default to 0, disabling SELinux at bootup.  If this option is
-	  set to 1 (one), the SELinux kernel parameter will default to 1,
-	  enabling SELinux at bootup.
-
-	  If you are unsure how to answer this question, answer 1.
-
 config SECURITY_SELINUX_DISABLE
 	bool "NSA SELinux runtime disable"
 	depends on SECURITY_SELINUX
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 71a10fedecb3..8f5eea097612 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -120,20 +120,7 @@ __setup("enforcing=", enforcing_setup);
 #define selinux_enforcing_boot 1
 #endif
 
-#ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
-int selinux_enabled = CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE;
-
-static int __init selinux_enabled_setup(char *str)
-{
-	unsigned long enabled;
-	if (!kstrtoul(str, 0, &enabled))
-		selinux_enabled = enabled ? 1 : 0;
-	return 1;
-}
-__setup("selinux=", selinux_enabled_setup);
-#else
-int selinux_enabled = 1;
-#endif
+int selinux_enabled __lsm_ro_after_init;
 
 static unsigned int selinux_checkreqprot_boot =
 	CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE;
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 24/32] LSM: Build ordered list of ordered LSMs for init
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (23 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 23/32] selinux: " Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 25/32] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
                   ` (7 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This constructs a list of ordered LSMs to initialize, using a hard-coded
list of only "integrity": minor LSMs continue to have direct hook calls,
and major LSMs continue to initialize separately.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/security.c | 59 +++++++++++++++++++++++++++++++++++++++------
 1 file changed, 52 insertions(+), 7 deletions(-)

diff --git a/security/security.c b/security/security.c
index 40b9f508b856..8706b42b4d44 100644
--- a/security/security.c
+++ b/security/security.c
@@ -34,6 +34,9 @@
 
 #define MAX_LSM_EVM_XATTR	2
 
+/* How many LSMs were built into the kernel? */
+#define LSM_COUNT (__end_lsm_info - __start_lsm_info)
+
 struct security_hook_heads security_hook_heads __lsm_ro_after_init;
 static ATOMIC_NOTIFIER_HEAD(lsm_notifier_chain);
 
@@ -45,6 +48,9 @@ static __initdata const char *chosen_major_lsm;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
 
+/* Ordered list of LSMs to initialize. */
+static __initdata struct lsm_info **ordered_lsms;
+
 static __initdata bool debug;
 #define init_debug(...)						\
 	do {							\
@@ -88,6 +94,45 @@ static void __init set_enabled(struct lsm_info *lsm, bool enabled)
 	}
 }
 
+/* Is an LSM already listed in the ordered LSMs list? */
+static bool __init exists_ordered_lsm(struct lsm_info *lsm)
+{
+	struct lsm_info **check;
+
+	for (check = ordered_lsms; *check; check++)
+		if (*check == lsm)
+			return true;
+
+	return false;
+}
+
+/* Append an LSM to the list of ordered LSMs to initialize. */
+static int last_lsm __initdata;
+static void __init append_ordered_lsm(struct lsm_info *lsm, const char *from)
+{
+	/* Ignore duplicate selections. */
+	if (exists_ordered_lsm(lsm))
+		return;
+
+	if (WARN(last_lsm == LSM_COUNT, "%s: out of LSM slots!?\n", from))
+		return;
+
+	ordered_lsms[last_lsm++] = lsm;
+	init_debug("%s ordering: %s (%sabled)\n", from, lsm->name,
+		   is_enabled(lsm) ? "en" : "dis");
+}
+
+/* Populate ordered LSMs list from hard-coded list of LSMs. */
+static void __init prepare_lsm_order(void)
+{
+	struct lsm_info *lsm;
+
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if (strcmp(lsm->name, "integrity") == 0)
+			append_ordered_lsm(lsm, "builtin");
+	}
+}
+
 /* Is an LSM allowed to be initialized? */
 static bool __init lsm_allowed(struct lsm_info *lsm)
 {
@@ -118,14 +163,10 @@ static void __init maybe_initialize_lsm(struct lsm_info *lsm)
 
 static void __init ordered_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;
+	struct lsm_info **lsm;
 
-		maybe_initialize_lsm(lsm);
-	}
+	for (lsm = ordered_lsms; *lsm; lsm++)
+		maybe_initialize_lsm(*lsm);
 }
 
 static void __init major_lsm_init(void)
@@ -207,6 +248,8 @@ int __init security_init(void)
 	for (i = 0; i < sizeof(security_hook_heads) / sizeof(struct hlist_head);
 	     i++)
 		INIT_HLIST_HEAD(&list[i]);
+	ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
+				GFP_KERNEL);
 
 	/* Figure out which LSMs are enabled and disabled. */
 	prepare_lsm_enable();
@@ -219,6 +262,7 @@ int __init security_init(void)
 	loadpin_add_hooks();
 
 	/* Load LSMs in specified order. */
+	prepare_lsm_order();
 	ordered_lsm_init();
 
 	/*
@@ -226,6 +270,7 @@ int __init security_init(void)
 	 */
 	major_lsm_init();
 
+	kfree(ordered_lsms);
 	return 0;
 }
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 24/32] LSM: Build ordered list of ordered LSMs for init
  2018-10-02  0:54 ` [PATCH security-next v4 24/32] LSM: Build ordered list of ordered LSMs for init Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This constructs a list of ordered LSMs to initialize, using a hard-coded
list of only "integrity": minor LSMs continue to have direct hook calls,
and major LSMs continue to initialize separately.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/security.c | 59 +++++++++++++++++++++++++++++++++++++++------
 1 file changed, 52 insertions(+), 7 deletions(-)

diff --git a/security/security.c b/security/security.c
index 40b9f508b856..8706b42b4d44 100644
--- a/security/security.c
+++ b/security/security.c
@@ -34,6 +34,9 @@
 
 #define MAX_LSM_EVM_XATTR	2
 
+/* How many LSMs were built into the kernel? */
+#define LSM_COUNT (__end_lsm_info - __start_lsm_info)
+
 struct security_hook_heads security_hook_heads __lsm_ro_after_init;
 static ATOMIC_NOTIFIER_HEAD(lsm_notifier_chain);
 
@@ -45,6 +48,9 @@ static __initdata const char *chosen_major_lsm;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
 
+/* Ordered list of LSMs to initialize. */
+static __initdata struct lsm_info **ordered_lsms;
+
 static __initdata bool debug;
 #define init_debug(...)						\
 	do {							\
@@ -88,6 +94,45 @@ static void __init set_enabled(struct lsm_info *lsm, bool enabled)
 	}
 }
 
+/* Is an LSM already listed in the ordered LSMs list? */
+static bool __init exists_ordered_lsm(struct lsm_info *lsm)
+{
+	struct lsm_info **check;
+
+	for (check = ordered_lsms; *check; check++)
+		if (*check == lsm)
+			return true;
+
+	return false;
+}
+
+/* Append an LSM to the list of ordered LSMs to initialize. */
+static int last_lsm __initdata;
+static void __init append_ordered_lsm(struct lsm_info *lsm, const char *from)
+{
+	/* Ignore duplicate selections. */
+	if (exists_ordered_lsm(lsm))
+		return;
+
+	if (WARN(last_lsm == LSM_COUNT, "%s: out of LSM slots!?\n", from))
+		return;
+
+	ordered_lsms[last_lsm++] = lsm;
+	init_debug("%s ordering: %s (%sabled)\n", from, lsm->name,
+		   is_enabled(lsm) ? "en" : "dis");
+}
+
+/* Populate ordered LSMs list from hard-coded list of LSMs. */
+static void __init prepare_lsm_order(void)
+{
+	struct lsm_info *lsm;
+
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if (strcmp(lsm->name, "integrity") == 0)
+			append_ordered_lsm(lsm, "builtin");
+	}
+}
+
 /* Is an LSM allowed to be initialized? */
 static bool __init lsm_allowed(struct lsm_info *lsm)
 {
@@ -118,14 +163,10 @@ static void __init maybe_initialize_lsm(struct lsm_info *lsm)
 
 static void __init ordered_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;
+	struct lsm_info **lsm;
 
-		maybe_initialize_lsm(lsm);
-	}
+	for (lsm = ordered_lsms; *lsm; lsm++)
+		maybe_initialize_lsm(*lsm);
 }
 
 static void __init major_lsm_init(void)
@@ -207,6 +248,8 @@ int __init security_init(void)
 	for (i = 0; i < sizeof(security_hook_heads) / sizeof(struct hlist_head);
 	     i++)
 		INIT_HLIST_HEAD(&list[i]);
+	ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
+				GFP_KERNEL);
 
 	/* Figure out which LSMs are enabled and disabled. */
 	prepare_lsm_enable();
@@ -219,6 +262,7 @@ int __init security_init(void)
 	loadpin_add_hooks();
 
 	/* Load LSMs in specified order. */
+	prepare_lsm_order();
 	ordered_lsm_init();
 
 	/*
@@ -226,6 +270,7 @@ int __init security_init(void)
 	 */
 	major_lsm_init();
 
+	kfree(ordered_lsms);
 	return 0;
 }
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 25/32] LSM: Introduce CONFIG_LSM_ORDER
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (24 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 24/32] LSM: Build ordered list of ordered LSMs for init Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:54 ` [PATCH security-next v4 26/32] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
                   ` (6 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This provides a way to declare LSM initialization order via Kconfig.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/Kconfig    | 16 ++++++++++++++++
 security/security.c | 40 +++++++++++++++++++++++++++++++++++++---
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 1e57619fd561..c68520d97fd7 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -286,5 +286,21 @@ config LSM_ENABLE
 	  changed with the "lsm.enable=" and "lsm.disable=" boot
 	  parameters.
 
+	  Note that any enabled exclusive LSM modules will be initialized
+	  based on LSM ordering, automatically disabling any following
+	  exclusive LSMs. See CONFIG_LSM_ORDER for more details on
+	  changing LSM initialization order.
+
+config LSM_ORDER
+	string "Default initialization order of builtin LSMs"
+	default "integrity"
+	help
+	  A comma-separated list of LSMs, in initialization order.
+	  Any LSMs left off this list will be link-order initialized
+	  after any listed LSMs. Any LSMs listed here but not built in
+	  the kernel will be ignored.
+
+	  If unsure, leave this as the default.
+
 endmenu
 
diff --git a/security/security.c b/security/security.c
index 8706b42b4d44..0510bb8e0af0 100644
--- a/security/security.c
+++ b/security/security.c
@@ -47,6 +47,7 @@ static __initdata const char *chosen_lsm_disable;
 static __initdata const char *chosen_major_lsm;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
+static __initconst const char * const builtin_lsm_order = CONFIG_LSM_ORDER;
 
 /* Ordered list of LSMs to initialize. */
 static __initdata struct lsm_info **ordered_lsms;
@@ -122,14 +123,47 @@ static void __init append_ordered_lsm(struct lsm_info *lsm, const char *from)
 		   is_enabled(lsm) ? "en" : "dis");
 }
 
-/* Populate ordered LSMs list from hard-coded list of LSMs. */
+/* Populate ordered LSMs list from given string. */
+static void __init parse_lsm_order(const char *order, const char *origin)
+{
+	struct lsm_info *lsm;
+	char *sep, *name, *next;
+
+	if (!order)
+		return;
+
+	sep = kstrdup(order, GFP_KERNEL);
+	next = sep;
+	/* Walk the list, looking for matching LSMs. */
+	while ((name = strsep(&next, ",")) != NULL) {
+		bool found = false;
+
+		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+			if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0 &&
+			    strcmp(lsm->name, name) == 0) {
+				append_ordered_lsm(lsm, origin);
+				found = true;
+			}
+		}
+
+		if (!found)
+			init_debug("%s ignored: %s\n", origin, name);
+	}
+	kfree(sep);
+}
+
+/* Populate ordered LSMs list from builtin list of LSMs. */
 static void __init prepare_lsm_order(void)
 {
 	struct lsm_info *lsm;
 
+	/* Parse order from builtin list. */
+	parse_lsm_order(builtin_lsm_order, "builtin");
+
+	/* Add any missing LSMs, in link order. */
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
-		if (strcmp(lsm->name, "integrity") == 0)
-			append_ordered_lsm(lsm, "builtin");
+		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
+			append_ordered_lsm(lsm, "link-time");
 	}
 }
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 25/32] LSM: Introduce CONFIG_LSM_ORDER
  2018-10-02  0:54 ` [PATCH security-next v4 25/32] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This provides a way to declare LSM initialization order via Kconfig.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/Kconfig    | 16 ++++++++++++++++
 security/security.c | 40 +++++++++++++++++++++++++++++++++++++---
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 1e57619fd561..c68520d97fd7 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -286,5 +286,21 @@ config LSM_ENABLE
 	  changed with the "lsm.enable=" and "lsm.disable=" boot
 	  parameters.
 
+	  Note that any enabled exclusive LSM modules will be initialized
+	  based on LSM ordering, automatically disabling any following
+	  exclusive LSMs. See CONFIG_LSM_ORDER for more details on
+	  changing LSM initialization order.
+
+config LSM_ORDER
+	string "Default initialization order of builtin LSMs"
+	default "integrity"
+	help
+	  A comma-separated list of LSMs, in initialization order.
+	  Any LSMs left off this list will be link-order initialized
+	  after any listed LSMs. Any LSMs listed here but not built in
+	  the kernel will be ignored.
+
+	  If unsure, leave this as the default.
+
 endmenu
 
diff --git a/security/security.c b/security/security.c
index 8706b42b4d44..0510bb8e0af0 100644
--- a/security/security.c
+++ b/security/security.c
@@ -47,6 +47,7 @@ static __initdata const char *chosen_lsm_disable;
 static __initdata const char *chosen_major_lsm;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
+static __initconst const char * const builtin_lsm_order = CONFIG_LSM_ORDER;
 
 /* Ordered list of LSMs to initialize. */
 static __initdata struct lsm_info **ordered_lsms;
@@ -122,14 +123,47 @@ static void __init append_ordered_lsm(struct lsm_info *lsm, const char *from)
 		   is_enabled(lsm) ? "en" : "dis");
 }
 
-/* Populate ordered LSMs list from hard-coded list of LSMs. */
+/* Populate ordered LSMs list from given string. */
+static void __init parse_lsm_order(const char *order, const char *origin)
+{
+	struct lsm_info *lsm;
+	char *sep, *name, *next;
+
+	if (!order)
+		return;
+
+	sep = kstrdup(order, GFP_KERNEL);
+	next = sep;
+	/* Walk the list, looking for matching LSMs. */
+	while ((name = strsep(&next, ",")) != NULL) {
+		bool found = false;
+
+		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+			if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0 &&
+			    strcmp(lsm->name, name) == 0) {
+				append_ordered_lsm(lsm, origin);
+				found = true;
+			}
+		}
+
+		if (!found)
+			init_debug("%s ignored: %s\n", origin, name);
+	}
+	kfree(sep);
+}
+
+/* Populate ordered LSMs list from builtin list of LSMs. */
 static void __init prepare_lsm_order(void)
 {
 	struct lsm_info *lsm;
 
+	/* Parse order from builtin list. */
+	parse_lsm_order(builtin_lsm_order, "builtin");
+
+	/* Add any missing LSMs, in link order. */
 	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
-		if (strcmp(lsm->name, "integrity") == 0)
-			append_ordered_lsm(lsm, "builtin");
+		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
+			append_ordered_lsm(lsm, "link-time");
 	}
 }
 
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 26/32] LSM: Introduce "lsm.order=" for boottime ordering
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (25 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 25/32] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
@ 2018-10-02  0:54 ` Kees Cook
  2018-10-02  0:54   ` Kees Cook
  2018-10-02  0:55 ` [PATCH security-next v4 27/32] LoadPin: Initialize as ordered LSM Kees Cook
                   ` (5 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Provide a way to reorder LSM initialization using the new "lsm.order="
comma-separated list of LSMs. Any LSMs not listed will be added in builtin
order.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  6 ++++++
 security/security.c                             | 14 +++++++++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0d10ab3d020e..7e01b7a1e73d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2286,6 +2286,12 @@
 			at boot time. This overrides any omissions from
 			CONFIG_LSM_ENABLE.
 
+	lsm.order=lsm1,...,lsmN
+			[SECURITY] Choose order of enabled LSM
+			initialization. Any builtin LSMs not listed here
+			will be implicitly appended to the list in builtin
+			order.
+
 	machvec=	[IA-64] Force the use of a particular machine-vector
 			(machvec) in a generic kernel.
 			Example: machvec=hpzx1_swiotlb
diff --git a/security/security.c b/security/security.c
index 0510bb8e0af0..6fafad44b85e 100644
--- a/security/security.c
+++ b/security/security.c
@@ -44,6 +44,7 @@ char *lsm_names;
 /* Boot-time LSM user choice */
 static __initdata const char *chosen_lsm_enable;
 static __initdata const char *chosen_lsm_disable;
+static __initdata const char *chosen_lsm_order;
 static __initdata const char *chosen_major_lsm;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
@@ -152,11 +153,14 @@ static void __init parse_lsm_order(const char *order, const char *origin)
 	kfree(sep);
 }
 
-/* Populate ordered LSMs list from builtin list of LSMs. */
+/* Populate ordered LSMs list from commandline and builtin list of LSMs. */
 static void __init prepare_lsm_order(void)
 {
 	struct lsm_info *lsm;
 
+	/* Parse order from commandline, if present. */
+	parse_lsm_order(chosen_lsm_order, "cmdline");
+
 	/* Parse order from builtin list. */
 	parse_lsm_order(builtin_lsm_order, "builtin");
 
@@ -316,6 +320,14 @@ static int __init choose_major_lsm(char *str)
 }
 __setup("security=", choose_major_lsm);
 
+/* Explicitly choose LSM initialization order. */
+static int __init choose_lsm_order(char *str)
+{
+	chosen_lsm_order = str;
+	return 1;
+}
+__setup("lsm.order=", choose_lsm_order);
+
 /* Enable LSM order debugging. */
 static int __init enable_debug(char *str)
 {
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 26/32] LSM: Introduce "lsm.order=" for boottime ordering
  2018-10-02  0:54 ` [PATCH security-next v4 26/32] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
@ 2018-10-02  0:54   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:54 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

Provide a way to reorder LSM initialization using the new "lsm.order="
comma-separated list of LSMs. Any LSMs not listed will be added in builtin
order.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  6 ++++++
 security/security.c                             | 14 +++++++++++++-
 2 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0d10ab3d020e..7e01b7a1e73d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2286,6 +2286,12 @@
 			at boot time. This overrides any omissions from
 			CONFIG_LSM_ENABLE.
 
+	lsm.order=lsm1,...,lsmN
+			[SECURITY] Choose order of enabled LSM
+			initialization. Any builtin LSMs not listed here
+			will be implicitly appended to the list in builtin
+			order.
+
 	machvec=	[IA-64] Force the use of a particular machine-vector
 			(machvec) in a generic kernel.
 			Example: machvec=hpzx1_swiotlb
diff --git a/security/security.c b/security/security.c
index 0510bb8e0af0..6fafad44b85e 100644
--- a/security/security.c
+++ b/security/security.c
@@ -44,6 +44,7 @@ char *lsm_names;
 /* Boot-time LSM user choice */
 static __initdata const char *chosen_lsm_enable;
 static __initdata const char *chosen_lsm_disable;
+static __initdata const char *chosen_lsm_order;
 static __initdata const char *chosen_major_lsm;
 
 static __initconst const char * const builtin_lsm_enable = CONFIG_LSM_ENABLE;
@@ -152,11 +153,14 @@ static void __init parse_lsm_order(const char *order, const char *origin)
 	kfree(sep);
 }
 
-/* Populate ordered LSMs list from builtin list of LSMs. */
+/* Populate ordered LSMs list from commandline and builtin list of LSMs. */
 static void __init prepare_lsm_order(void)
 {
 	struct lsm_info *lsm;
 
+	/* Parse order from commandline, if present. */
+	parse_lsm_order(chosen_lsm_order, "cmdline");
+
 	/* Parse order from builtin list. */
 	parse_lsm_order(builtin_lsm_order, "builtin");
 
@@ -316,6 +320,14 @@ static int __init choose_major_lsm(char *str)
 }
 __setup("security=", choose_major_lsm);
 
+/* Explicitly choose LSM initialization order. */
+static int __init choose_lsm_order(char *str)
+{
+	chosen_lsm_order = str;
+	return 1;
+}
+__setup("lsm.order=", choose_lsm_order);
+
 /* Enable LSM order debugging. */
 static int __init enable_debug(char *str)
 {
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 27/32] LoadPin: Initialize as ordered LSM
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (26 preceding siblings ...)
  2018-10-02  0:54 ` [PATCH security-next v4 26/32] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
@ 2018-10-02  0:55 ` Kees Cook
  2018-10-02  0:55   ` Kees Cook
  2018-10-02  0:55 ` [PATCH security-next v4 28/32] Yama: " Kees Cook
                   ` (4 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This converts LoadPin from being a direct "minor" LSM into an ordered LSM.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h  | 5 -----
 security/Kconfig           | 2 +-
 security/loadpin/loadpin.c | 8 +++++++-
 security/security.c        | 1 -
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index b026ea93ff01..098ccf2caa0e 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2091,10 +2091,5 @@ extern void __init yama_add_hooks(void);
 #else
 static inline void __init yama_add_hooks(void) { }
 #endif
-#ifdef CONFIG_SECURITY_LOADPIN
-void __init loadpin_add_hooks(void);
-#else
-static inline void loadpin_add_hooks(void) { };
-#endif
 
 #endif /* ! __LINUX_LSM_HOOKS_H */
diff --git a/security/Kconfig b/security/Kconfig
index c68520d97fd7..e59cb9296316 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -293,7 +293,7 @@ config LSM_ENABLE
 
 config LSM_ORDER
 	string "Default initialization order of builtin LSMs"
-	default "integrity"
+	default "loadpin,integrity"
 	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/loadpin/loadpin.c b/security/loadpin/loadpin.c
index d8a68a6f6fef..dab42bfa1e4a 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -184,13 +184,19 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
 	LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
 };
 
-void __init loadpin_add_hooks(void)
+static int __init loadpin_init(void)
 {
 	pr_info("ready to pin (currently %senforcing)\n",
 		enforcing ? "" : "not ");
 	security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
+	return 0;
 }
 
+DEFINE_LSM(loadpin) = {
+	.name = "loadpin",
+	.init = loadpin_init,
+};
+
 /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
 module_param(enforcing, int, 0);
 MODULE_PARM_DESC(enforcing, "Enforce module/firmware pinning");
diff --git a/security/security.c b/security/security.c
index 6fafad44b85e..6957f5f50483 100644
--- a/security/security.c
+++ b/security/security.c
@@ -297,7 +297,6 @@ int __init security_init(void)
 	 */
 	capability_add_hooks();
 	yama_add_hooks();
-	loadpin_add_hooks();
 
 	/* Load LSMs in specified order. */
 	prepare_lsm_order();
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 27/32] LoadPin: Initialize as ordered LSM
  2018-10-02  0:55 ` [PATCH security-next v4 27/32] LoadPin: Initialize as ordered LSM Kees Cook
@ 2018-10-02  0:55   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This converts LoadPin from being a direct "minor" LSM into an ordered LSM.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h  | 5 -----
 security/Kconfig           | 2 +-
 security/loadpin/loadpin.c | 8 +++++++-
 security/security.c        | 1 -
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index b026ea93ff01..098ccf2caa0e 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2091,10 +2091,5 @@ extern void __init yama_add_hooks(void);
 #else
 static inline void __init yama_add_hooks(void) { }
 #endif
-#ifdef CONFIG_SECURITY_LOADPIN
-void __init loadpin_add_hooks(void);
-#else
-static inline void loadpin_add_hooks(void) { };
-#endif
 
 #endif /* ! __LINUX_LSM_HOOKS_H */
diff --git a/security/Kconfig b/security/Kconfig
index c68520d97fd7..e59cb9296316 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -293,7 +293,7 @@ config LSM_ENABLE
 
 config LSM_ORDER
 	string "Default initialization order of builtin LSMs"
-	default "integrity"
+	default "loadpin,integrity"
 	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/loadpin/loadpin.c b/security/loadpin/loadpin.c
index d8a68a6f6fef..dab42bfa1e4a 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -184,13 +184,19 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
 	LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
 };
 
-void __init loadpin_add_hooks(void)
+static int __init loadpin_init(void)
 {
 	pr_info("ready to pin (currently %senforcing)\n",
 		enforcing ? "" : "not ");
 	security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
+	return 0;
 }
 
+DEFINE_LSM(loadpin) = {
+	.name = "loadpin",
+	.init = loadpin_init,
+};
+
 /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
 module_param(enforcing, int, 0);
 MODULE_PARM_DESC(enforcing, "Enforce module/firmware pinning");
diff --git a/security/security.c b/security/security.c
index 6fafad44b85e..6957f5f50483 100644
--- a/security/security.c
+++ b/security/security.c
@@ -297,7 +297,6 @@ int __init security_init(void)
 	 */
 	capability_add_hooks();
 	yama_add_hooks();
-	loadpin_add_hooks();
 
 	/* Load LSMs in specified order. */
 	prepare_lsm_order();
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 28/32] Yama: Initialize as ordered LSM
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (27 preceding siblings ...)
  2018-10-02  0:55 ` [PATCH security-next v4 27/32] LoadPin: Initialize as ordered LSM Kees Cook
@ 2018-10-02  0:55 ` Kees Cook
  2018-10-02  0:55   ` Kees Cook
  2018-10-02  0:55 ` [PATCH security-next v4 29/32] LSM: Introduce enum lsm_order Kees Cook
                   ` (3 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This converts Yama from being a direct "minor" LSM into an ordered LSM.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h | 5 -----
 security/Kconfig          | 2 +-
 security/security.c       | 1 -
 security/yama/yama_lsm.c  | 8 +++++++-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 098ccf2caa0e..63a6caaee8e6 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2086,10 +2086,5 @@ static inline void security_delete_hooks(struct security_hook_list *hooks,
 #endif /* CONFIG_SECURITY_WRITABLE_HOOKS */
 
 extern void __init capability_add_hooks(void);
-#ifdef CONFIG_SECURITY_YAMA
-extern void __init yama_add_hooks(void);
-#else
-static inline void __init yama_add_hooks(void) { }
-#endif
 
 #endif /* ! __LINUX_LSM_HOOKS_H */
diff --git a/security/Kconfig b/security/Kconfig
index e59cb9296316..c459d2b4c7bd 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -293,7 +293,7 @@ config LSM_ENABLE
 
 config LSM_ORDER
 	string "Default initialization order of builtin LSMs"
-	default "loadpin,integrity"
+	default "yama,loadpin,integrity"
 	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 6957f5f50483..44c23d23158e 100644
--- a/security/security.c
+++ b/security/security.c
@@ -296,7 +296,6 @@ int __init security_init(void)
 	 * Load minor LSMs, with the capability module always first.
 	 */
 	capability_add_hooks();
-	yama_add_hooks();
 
 	/* Load LSMs in specified order. */
 	prepare_lsm_order();
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index ffda91a4a1aa..eb1da1303d2e 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -477,9 +477,15 @@ static void __init yama_init_sysctl(void)
 static inline void yama_init_sysctl(void) { }
 #endif /* CONFIG_SYSCTL */
 
-void __init yama_add_hooks(void)
+static int __init yama_init(void)
 {
 	pr_info("Yama: becoming mindful.\n");
 	security_add_hooks(yama_hooks, ARRAY_SIZE(yama_hooks), "yama");
 	yama_init_sysctl();
+	return 0;
 }
+
+DEFINE_LSM(yama) = {
+	.name = "yama",
+	.init = yama_init,
+};
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 28/32] Yama: Initialize as ordered LSM
  2018-10-02  0:55 ` [PATCH security-next v4 28/32] Yama: " Kees Cook
@ 2018-10-02  0:55   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This converts Yama from being a direct "minor" LSM into an ordered LSM.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h | 5 -----
 security/Kconfig          | 2 +-
 security/security.c       | 1 -
 security/yama/yama_lsm.c  | 8 +++++++-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 098ccf2caa0e..63a6caaee8e6 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2086,10 +2086,5 @@ static inline void security_delete_hooks(struct security_hook_list *hooks,
 #endif /* CONFIG_SECURITY_WRITABLE_HOOKS */
 
 extern void __init capability_add_hooks(void);
-#ifdef CONFIG_SECURITY_YAMA
-extern void __init yama_add_hooks(void);
-#else
-static inline void __init yama_add_hooks(void) { }
-#endif
 
 #endif /* ! __LINUX_LSM_HOOKS_H */
diff --git a/security/Kconfig b/security/Kconfig
index e59cb9296316..c459d2b4c7bd 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -293,7 +293,7 @@ config LSM_ENABLE
 
 config LSM_ORDER
 	string "Default initialization order of builtin LSMs"
-	default "loadpin,integrity"
+	default "yama,loadpin,integrity"
 	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 6957f5f50483..44c23d23158e 100644
--- a/security/security.c
+++ b/security/security.c
@@ -296,7 +296,6 @@ int __init security_init(void)
 	 * Load minor LSMs, with the capability module always first.
 	 */
 	capability_add_hooks();
-	yama_add_hooks();
 
 	/* Load LSMs in specified order. */
 	prepare_lsm_order();
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index ffda91a4a1aa..eb1da1303d2e 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -477,9 +477,15 @@ static void __init yama_init_sysctl(void)
 static inline void yama_init_sysctl(void) { }
 #endif /* CONFIG_SYSCTL */
 
-void __init yama_add_hooks(void)
+static int __init yama_init(void)
 {
 	pr_info("Yama: becoming mindful.\n");
 	security_add_hooks(yama_hooks, ARRAY_SIZE(yama_hooks), "yama");
 	yama_init_sysctl();
+	return 0;
 }
+
+DEFINE_LSM(yama) = {
+	.name = "yama",
+	.init = yama_init,
+};
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 29/32] LSM: Introduce enum lsm_order
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (28 preceding siblings ...)
  2018-10-02  0:55 ` [PATCH security-next v4 28/32] Yama: " Kees Cook
@ 2018-10-02  0:55 ` Kees Cook
  2018-10-02  0:55   ` Kees Cook
  2018-10-02  0:55 ` [PATCH security-next v4 30/32] capability: Initialize as LSM_ORDER_FIRST Kees Cook
                   ` (2 subsequent siblings)
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for distinguishing the "capability" LSM from other LSMs,
it must be ordered first. This introduces LSM_ORDER_MUTABLE for the
general LSMs, LSM_ORDER_FIRST for capabilities, and LSM_ORDER_LAST for
anything that must run last (e.g. Landlock may use this in the future).

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h |  7 +++++++
 security/security.c       | 18 ++++++++++++++++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 63a6caaee8e6..62bc230826e0 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2041,8 +2041,15 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 
 #define LSM_FLAG_LEGACY_MAJOR	BIT(0)
 
+enum lsm_order {
+	LSM_ORDER_FIRST = -1,	/* This is only for capabilities. */
+	LSM_ORDER_MUTABLE = 0,
+	LSM_ORDER_LAST,
+};
+
 struct lsm_info {
 	const char *name;	/* Required. */
+	enum lsm_order order;	/* Optional: default is LSM_ORDER_MUTABLE */
 	unsigned long flags;	/* Optional: flags describing LSM */
 	int *enabled;		/* Optional: set based on CONFIG_LSM_ENABLE */
 	int (*init)(void);	/* Required. */
diff --git a/security/security.c b/security/security.c
index 44c23d23158e..dac379518e60 100644
--- a/security/security.c
+++ b/security/security.c
@@ -140,7 +140,8 @@ static void __init parse_lsm_order(const char *order, const char *origin)
 		bool found = false;
 
 		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
-			if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0 &&
+			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;
@@ -158,6 +159,12 @@ static void __init prepare_lsm_order(void)
 {
 	struct lsm_info *lsm;
 
+	/* LSM_ORDER_FIRST is always first. */
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if (lsm->order == LSM_ORDER_FIRST)
+			append_ordered_lsm(lsm, "first");
+	}
+
 	/* Parse order from commandline, if present. */
 	parse_lsm_order(chosen_lsm_order, "cmdline");
 
@@ -166,9 +173,16 @@ 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->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
+		if (lsm->order == LSM_ORDER_MUTABLE &&
+		    (lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
 			append_ordered_lsm(lsm, "link-time");
 	}
+
+	/* LSM_ORDER_LAST is always last. */
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if (lsm->order == LSM_ORDER_LAST)
+			append_ordered_lsm(lsm, "last");
+	}
 }
 
 /* Is an LSM allowed to be initialized? */
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 29/32] LSM: Introduce enum lsm_order
  2018-10-02  0:55 ` [PATCH security-next v4 29/32] LSM: Introduce enum lsm_order Kees Cook
@ 2018-10-02  0:55   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In preparation for distinguishing the "capability" LSM from other LSMs,
it must be ordered first. This introduces LSM_ORDER_MUTABLE for the
general LSMs, LSM_ORDER_FIRST for capabilities, and LSM_ORDER_LAST for
anything that must run last (e.g. Landlock may use this in the future).

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h |  7 +++++++
 security/security.c       | 18 ++++++++++++++++--
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 63a6caaee8e6..62bc230826e0 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2041,8 +2041,15 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 
 #define LSM_FLAG_LEGACY_MAJOR	BIT(0)
 
+enum lsm_order {
+	LSM_ORDER_FIRST = -1,	/* This is only for capabilities. */
+	LSM_ORDER_MUTABLE = 0,
+	LSM_ORDER_LAST,
+};
+
 struct lsm_info {
 	const char *name;	/* Required. */
+	enum lsm_order order;	/* Optional: default is LSM_ORDER_MUTABLE */
 	unsigned long flags;	/* Optional: flags describing LSM */
 	int *enabled;		/* Optional: set based on CONFIG_LSM_ENABLE */
 	int (*init)(void);	/* Required. */
diff --git a/security/security.c b/security/security.c
index 44c23d23158e..dac379518e60 100644
--- a/security/security.c
+++ b/security/security.c
@@ -140,7 +140,8 @@ static void __init parse_lsm_order(const char *order, const char *origin)
 		bool found = false;
 
 		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
-			if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0 &&
+			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;
@@ -158,6 +159,12 @@ static void __init prepare_lsm_order(void)
 {
 	struct lsm_info *lsm;
 
+	/* LSM_ORDER_FIRST is always first. */
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if (lsm->order == LSM_ORDER_FIRST)
+			append_ordered_lsm(lsm, "first");
+	}
+
 	/* Parse order from commandline, if present. */
 	parse_lsm_order(chosen_lsm_order, "cmdline");
 
@@ -166,9 +173,16 @@ 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->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
+		if (lsm->order == LSM_ORDER_MUTABLE &&
+		    (lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
 			append_ordered_lsm(lsm, "link-time");
 	}
+
+	/* LSM_ORDER_LAST is always last. */
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if (lsm->order == LSM_ORDER_LAST)
+			append_ordered_lsm(lsm, "last");
+	}
 }
 
 /* Is an LSM allowed to be initialized? */
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 30/32] capability: Initialize as LSM_ORDER_FIRST
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (29 preceding siblings ...)
  2018-10-02  0:55 ` [PATCH security-next v4 29/32] LSM: Introduce enum lsm_order Kees Cook
@ 2018-10-02  0:55 ` Kees Cook
  2018-10-02  0:55   ` Kees Cook
  2018-10-02  0:55 ` [PATCH security-next v4 31/32] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
  2018-10-02  0:55 ` [PATCH security-next v4 32/32] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This converts capabilities to use the new LSM_ORDER_FIRST position.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h | 2 --
 security/commoncap.c      | 9 ++++++++-
 security/security.c       | 9 ++++-----
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 62bc230826e0..36e7a716fdfe 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2092,6 +2092,4 @@ static inline void security_delete_hooks(struct security_hook_list *hooks,
 #define __lsm_ro_after_init	__ro_after_init
 #endif /* CONFIG_SECURITY_WRITABLE_HOOKS */
 
-extern void __init capability_add_hooks(void);
-
 #endif /* ! __LINUX_LSM_HOOKS_H */
diff --git a/security/commoncap.c b/security/commoncap.c
index 2e489d6a3ac8..c928eb3fe784 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1366,10 +1366,17 @@ struct security_hook_list capability_hooks[] __lsm_ro_after_init = {
 	LSM_HOOK_INIT(vm_enough_memory, cap_vm_enough_memory),
 };
 
-void __init capability_add_hooks(void)
+static int __init capability_init(void)
 {
 	security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks),
 				"capability");
+	return 0;
 }
 
+DEFINE_LSM(capability) = {
+	.name = "capability",
+	.order = LSM_ORDER_FIRST,
+	.init = capability_init,
+};
+
 #endif /* CONFIG_SECURITY */
diff --git a/security/security.c b/security/security.c
index dac379518e60..813dab3b5b97 100644
--- a/security/security.c
+++ b/security/security.c
@@ -62,6 +62,10 @@ static __initdata bool debug;
 
 static bool __init is_enabled(struct lsm_info *lsm)
 {
+	/* LSM_ORDER_FIRST is always enabled. */
+	if (lsm->order == LSM_ORDER_FIRST)
+		return true;
+
 	if (WARN_ON(!lsm->enabled))
 		return false;
 
@@ -306,11 +310,6 @@ int __init security_init(void)
 	/* Figure out which LSMs are enabled and disabled. */
 	prepare_lsm_enable();
 
-	/*
-	 * Load minor LSMs, with the capability module always first.
-	 */
-	capability_add_hooks();
-
 	/* Load LSMs in specified order. */
 	prepare_lsm_order();
 	ordered_lsm_init();
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 30/32] capability: Initialize as LSM_ORDER_FIRST
  2018-10-02  0:55 ` [PATCH security-next v4 30/32] capability: Initialize as LSM_ORDER_FIRST Kees Cook
@ 2018-10-02  0:55   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

This converts capabilities to use the new LSM_ORDER_FIRST position.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h | 2 --
 security/commoncap.c      | 9 ++++++++-
 security/security.c       | 9 ++++-----
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 62bc230826e0..36e7a716fdfe 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2092,6 +2092,4 @@ static inline void security_delete_hooks(struct security_hook_list *hooks,
 #define __lsm_ro_after_init	__ro_after_init
 #endif /* CONFIG_SECURITY_WRITABLE_HOOKS */
 
-extern void __init capability_add_hooks(void);
-
 #endif /* ! __LINUX_LSM_HOOKS_H */
diff --git a/security/commoncap.c b/security/commoncap.c
index 2e489d6a3ac8..c928eb3fe784 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1366,10 +1366,17 @@ struct security_hook_list capability_hooks[] __lsm_ro_after_init = {
 	LSM_HOOK_INIT(vm_enough_memory, cap_vm_enough_memory),
 };
 
-void __init capability_add_hooks(void)
+static int __init capability_init(void)
 {
 	security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks),
 				"capability");
+	return 0;
 }
 
+DEFINE_LSM(capability) = {
+	.name = "capability",
+	.order = LSM_ORDER_FIRST,
+	.init = capability_init,
+};
+
 #endif /* CONFIG_SECURITY */
diff --git a/security/security.c b/security/security.c
index dac379518e60..813dab3b5b97 100644
--- a/security/security.c
+++ b/security/security.c
@@ -62,6 +62,10 @@ static __initdata bool debug;
 
 static bool __init is_enabled(struct lsm_info *lsm)
 {
+	/* LSM_ORDER_FIRST is always enabled. */
+	if (lsm->order == LSM_ORDER_FIRST)
+		return true;
+
 	if (WARN_ON(!lsm->enabled))
 		return false;
 
@@ -306,11 +310,6 @@ int __init security_init(void)
 	/* Figure out which LSMs are enabled and disabled. */
 	prepare_lsm_enable();
 
-	/*
-	 * Load minor LSMs, with the capability module always first.
-	 */
-	capability_add_hooks();
-
 	/* Load LSMs in specified order. */
 	prepare_lsm_order();
 	ordered_lsm_init();
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 31/32] LSM: Separate idea of "major" LSM from "exclusive" LSM
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (30 preceding siblings ...)
  2018-10-02  0:55 ` [PATCH security-next v4 30/32] capability: Initialize as LSM_ORDER_FIRST Kees Cook
@ 2018-10-02  0:55 ` Kees Cook
  2018-10-02  0:55   ` Kees Cook
  2018-10-02  0:55 ` [PATCH security-next v4 32/32] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In order to both support old "security=" Legacy Major LSM selection, and
handling real exclusivity, this creates LSM_FLAG_EXCLUSIVE and updates
the selection logic to handle them.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h  |  1 +
 security/apparmor/lsm.c    |  2 +-
 security/security.c        | 12 ++++++++++++
 security/selinux/hooks.c   |  2 +-
 security/smack/smack_lsm.c |  2 +-
 security/tomoyo/tomoyo.c   |  2 +-
 6 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 36e7a716fdfe..2c9cf89a20ad 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2040,6 +2040,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
 #define LSM_FLAG_LEGACY_MAJOR	BIT(0)
+#define LSM_FLAG_EXCLUSIVE	BIT(1)
 
 enum lsm_order {
 	LSM_ORDER_FIRST = -1,	/* This is only for capabilities. */
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 4cd96a66ed6f..4eb74a6f2020 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1599,7 +1599,7 @@ static int __init apparmor_init(void)
 
 DEFINE_LSM(apparmor) = {
 	.name = "apparmor",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &apparmor_enabled,
 	.init = apparmor_init,
 };
diff --git a/security/security.c b/security/security.c
index 813dab3b5b97..7d542e78b7e8 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,6 +52,7 @@ static __initconst const char * const builtin_lsm_order = CONFIG_LSM_ORDER;
 
 /* Ordered list of LSMs to initialize. */
 static __initdata struct lsm_info **ordered_lsms;
+static __initdata struct lsm_info *exclusive;
 
 static __initdata bool debug;
 #define init_debug(...)						\
@@ -196,6 +197,12 @@ static bool __init lsm_allowed(struct lsm_info *lsm)
 	if (!is_enabled(lsm))
 		return false;
 
+	/* Not allowed if another exclusive LSM already initialized. */
+	if ((lsm->flags & LSM_FLAG_EXCLUSIVE) && exclusive) {
+		init_debug("exclusive disabled: %s\n", lsm->name);
+		return false;
+	}
+
 	return true;
 }
 
@@ -211,6 +218,11 @@ static void __init maybe_initialize_lsm(struct lsm_info *lsm)
 	if (enabled) {
 		int ret;
 
+		if ((lsm->flags & LSM_FLAG_EXCLUSIVE) && !exclusive) {
+			exclusive = lsm;
+			init_debug("exclusive: %s\n", lsm->name);
+		}
+
 		init_debug("initializing %s\n", lsm->name);
 		ret = lsm->init();
 		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 8f5eea097612..c070d3761ddc 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7181,7 +7181,7 @@ void selinux_complete_init(void)
    all processes and objects when they are created. */
 DEFINE_LSM(selinux) = {
 	.name = "selinux",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &selinux_enabled,
 	.init = selinux_init,
 };
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index f243044d5a55..92e4baa342f8 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4881,6 +4881,6 @@ static __init int smack_init(void)
  */
 DEFINE_LSM(smack) = {
 	.name = "smack",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = smack_init,
 };
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index a46f6bc1e97c..daff7d7897ad 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -550,6 +550,6 @@ static int __init tomoyo_init(void)
 
 DEFINE_LSM(tomoyo) = {
 	.name = "tomoyo",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = tomoyo_init,
 };
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 31/32] LSM: Separate idea of "major" LSM from "exclusive" LSM
  2018-10-02  0:55 ` [PATCH security-next v4 31/32] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
@ 2018-10-02  0:55   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

In order to both support old "security=" Legacy Major LSM selection, and
handling real exclusivity, this creates LSM_FLAG_EXCLUSIVE and updates
the selection logic to handle them.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h  |  1 +
 security/apparmor/lsm.c    |  2 +-
 security/security.c        | 12 ++++++++++++
 security/selinux/hooks.c   |  2 +-
 security/smack/smack_lsm.c |  2 +-
 security/tomoyo/tomoyo.c   |  2 +-
 6 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 36e7a716fdfe..2c9cf89a20ad 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2040,6 +2040,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
 #define LSM_FLAG_LEGACY_MAJOR	BIT(0)
+#define LSM_FLAG_EXCLUSIVE	BIT(1)
 
 enum lsm_order {
 	LSM_ORDER_FIRST = -1,	/* This is only for capabilities. */
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 4cd96a66ed6f..4eb74a6f2020 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1599,7 +1599,7 @@ static int __init apparmor_init(void)
 
 DEFINE_LSM(apparmor) = {
 	.name = "apparmor",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &apparmor_enabled,
 	.init = apparmor_init,
 };
diff --git a/security/security.c b/security/security.c
index 813dab3b5b97..7d542e78b7e8 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,6 +52,7 @@ static __initconst const char * const builtin_lsm_order = CONFIG_LSM_ORDER;
 
 /* Ordered list of LSMs to initialize. */
 static __initdata struct lsm_info **ordered_lsms;
+static __initdata struct lsm_info *exclusive;
 
 static __initdata bool debug;
 #define init_debug(...)						\
@@ -196,6 +197,12 @@ static bool __init lsm_allowed(struct lsm_info *lsm)
 	if (!is_enabled(lsm))
 		return false;
 
+	/* Not allowed if another exclusive LSM already initialized. */
+	if ((lsm->flags & LSM_FLAG_EXCLUSIVE) && exclusive) {
+		init_debug("exclusive disabled: %s\n", lsm->name);
+		return false;
+	}
+
 	return true;
 }
 
@@ -211,6 +218,11 @@ static void __init maybe_initialize_lsm(struct lsm_info *lsm)
 	if (enabled) {
 		int ret;
 
+		if ((lsm->flags & LSM_FLAG_EXCLUSIVE) && !exclusive) {
+			exclusive = lsm;
+			init_debug("exclusive: %s\n", lsm->name);
+		}
+
 		init_debug("initializing %s\n", lsm->name);
 		ret = lsm->init();
 		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 8f5eea097612..c070d3761ddc 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7181,7 +7181,7 @@ void selinux_complete_init(void)
    all processes and objects when they are created. */
 DEFINE_LSM(selinux) = {
 	.name = "selinux",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &selinux_enabled,
 	.init = selinux_init,
 };
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index f243044d5a55..92e4baa342f8 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4881,6 +4881,6 @@ static __init int smack_init(void)
  */
 DEFINE_LSM(smack) = {
 	.name = "smack",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = smack_init,
 };
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index a46f6bc1e97c..daff7d7897ad 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -550,6 +550,6 @@ static int __init tomoyo_init(void)
 
 DEFINE_LSM(tomoyo) = {
 	.name = "tomoyo",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = tomoyo_init,
 };
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 32/32] LSM: Add all exclusive LSMs to ordered initialization
  2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
                   ` (31 preceding siblings ...)
  2018-10-02  0:55 ` [PATCH security-next v4 31/32] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
@ 2018-10-02  0:55 ` Kees Cook
  2018-10-02  0:55   ` Kees Cook
  32 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

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. The old meaning of CONFIG_DEFAULT_SECURITY
is now captured by which exclusive LSM is listed first in the LSM order.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/Kconfig    | 43 ++++---------------------------------------
 security/security.c | 23 +----------------------
 2 files changed, 5 insertions(+), 61 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index c459d2b4c7bd..cc8bb1c344f5 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -239,43 +239,6 @@ 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_ENABLE
 	string "LSMs to enable at boot time"
 	default "all"
@@ -293,12 +256,14 @@ config LSM_ENABLE
 
 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
 	  after any listed LSMs. Any LSMs listed here but not built in
-	  the kernel will be ignored.
+	  the kernel will be ignored. If the boot parameter
+	  "lsm.order=" is used, it will override this order, with any
+	  unlisted LSMs falling back to the order of this config, etc.
 
 	  If unsure, leave this as the default.
 
diff --git a/security/security.c b/security/security.c
index 7d542e78b7e8..d682342b6450 100644
--- a/security/security.c
+++ b/security/security.c
@@ -146,7 +146,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;
@@ -178,8 +177,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");
 	}
 
@@ -237,18 +235,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);
-	}
-}
-
 static void __init parse_lsm_enable(const char *str,
 				    bool enabled)
 {
@@ -282,8 +268,6 @@ static void __init prepare_lsm_enable(void)
 	parse_lsm_enable(chosen_lsm_disable, false);
 
 	/* Process "security=", if given. */
-	if (!chosen_major_lsm)
-		chosen_major_lsm = CONFIG_DEFAULT_SECURITY;
 	if (chosen_major_lsm) {
 		struct lsm_info *lsm;
 
@@ -326,11 +310,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;
 }
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* [PATCH security-next v4 32/32] LSM: Add all exclusive LSMs to ordered initialization
  2018-10-02  0:55 ` [PATCH security-next v4 32/32] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
@ 2018-10-02  0:55   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  0:55 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

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. The old meaning of CONFIG_DEFAULT_SECURITY
is now captured by which exclusive LSM is listed first in the LSM order.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
---
 security/Kconfig    | 43 ++++---------------------------------------
 security/security.c | 23 +----------------------
 2 files changed, 5 insertions(+), 61 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index c459d2b4c7bd..cc8bb1c344f5 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -239,43 +239,6 @@ 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_ENABLE
 	string "LSMs to enable at boot time"
 	default "all"
@@ -293,12 +256,14 @@ config LSM_ENABLE
 
 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
 	  after any listed LSMs. Any LSMs listed here but not built in
-	  the kernel will be ignored.
+	  the kernel will be ignored. If the boot parameter
+	  "lsm.order=" is used, it will override this order, with any
+	  unlisted LSMs falling back to the order of this config, etc.
 
 	  If unsure, leave this as the default.
 
diff --git a/security/security.c b/security/security.c
index 7d542e78b7e8..d682342b6450 100644
--- a/security/security.c
+++ b/security/security.c
@@ -146,7 +146,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;
@@ -178,8 +177,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");
 	}
 
@@ -237,18 +235,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);
-	}
-}
-
 static void __init parse_lsm_enable(const char *str,
 				    bool enabled)
 {
@@ -282,8 +268,6 @@ static void __init prepare_lsm_enable(void)
 	parse_lsm_enable(chosen_lsm_disable, false);
 
 	/* Process "security=", if given. */
-	if (!chosen_major_lsm)
-		chosen_major_lsm = CONFIG_DEFAULT_SECURITY;
 	if (chosen_major_lsm) {
 		struct lsm_info *lsm;
 
@@ -326,11 +310,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;
 }
-- 
2.17.1

^ permalink raw reply related	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce"
  2018-10-02  0:54 ` [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce" Kees Cook
  2018-10-02  0:54   ` Kees Cook
@ 2018-10-02  1:06   ` Randy Dunlap
  2018-10-02  1:06     ` Randy Dunlap
  2018-10-02  4:47     ` Kees Cook
  1 sibling, 2 replies; 184+ messages in thread
From: Randy Dunlap @ 2018-10-02  1:06 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On 10/1/18 5:54 PM, Kees Cook wrote:
> LoadPin's "enable" setting is really about enforcement, not whether
> or not the LSM is using LSM hooks. Instead, split this out so that LSM
> enabling can be logically distinct from whether enforcement is happening
> (for example, the pinning happens when the LSM is enabled, but the pin
> is only checked when "enforce" is set). This allows LoadPin to continue

ISTB:             when "enforcing" is set).  ??

> to operate sanely in test environments once LSM enable/disable is
> centrally handled (i.e. we want LoadPin to be enabled separately from
> its enforcement).
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> Reviewed-by: John Johansen <john.johansen@canonical.com>
> ---
>  security/loadpin/Kconfig   |  4 ++--
>  security/loadpin/loadpin.c | 21 +++++++++++----------
>  2 files changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/security/loadpin/Kconfig b/security/loadpin/Kconfig
> index dd01aa91e521..8653608a3693 100644
> --- a/security/loadpin/Kconfig
> +++ b/security/loadpin/Kconfig
> @@ -10,10 +10,10 @@ config SECURITY_LOADPIN
>  	  have a root filesystem backed by a read-only device such as
>  	  dm-verity or a CDROM.
>  
> -config SECURITY_LOADPIN_ENABLED
> +config SECURITY_LOADPIN_ENFORCING
>  	bool "Enforce LoadPin at boot"
>  	depends on SECURITY_LOADPIN
>  	help
>  	  If selected, LoadPin will enforce pinning at boot. If not
>  	  selected, it can be enabled at boot with the kernel parameter
> -	  "loadpin.enabled=1".
> +	  "loadpin.enforcing=1".
> diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
> index 0716af28808a..d8a68a6f6fef 100644
> --- a/security/loadpin/loadpin.c
> +++ b/security/loadpin/loadpin.c
> @@ -44,7 +44,7 @@ static void report_load(const char *origin, struct file *file, char *operation)
>  	kfree(pathname);
>  }
>  
> -static int enabled = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENABLED);
> +static int enforcing = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCING);
>  static struct super_block *pinned_root;
>  static DEFINE_SPINLOCK(pinned_root_spinlock);
>  
> @@ -60,8 +60,8 @@ static struct ctl_path loadpin_sysctl_path[] = {
>  
>  static struct ctl_table loadpin_sysctl_table[] = {
>  	{
> -		.procname       = "enabled",
> -		.data           = &enabled,
> +		.procname       = "enforcing",
> +		.data           = &enforcing,
>  		.maxlen         = sizeof(int),
>  		.mode           = 0644,
>  		.proc_handler   = proc_dointvec_minmax,
> @@ -97,7 +97,7 @@ static void check_pinning_enforcement(struct super_block *mnt_sb)
>  					   loadpin_sysctl_table))
>  			pr_notice("sysctl registration failed!\n");
>  		else
> -			pr_info("load pinning can be disabled.\n");
> +			pr_info("enforcement can be disabled.\n");
>  	} else
>  		pr_info("load pinning engaged.\n");
>  }
> @@ -128,7 +128,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>  
>  	/* This handles the older init_module API that has a NULL file. */
>  	if (!file) {
> -		if (!enabled) {
> +		if (!enforcing) {
>  			report_load(origin, NULL, "old-api-pinning-ignored");
>  			return 0;
>  		}
> @@ -151,7 +151,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>  		 * Unlock now since it's only pinned_root we care about.
>  		 * In the worst case, we will (correctly) report pinning
>  		 * failures before we have announced that pinning is
> -		 * enabled. This would be purely cosmetic.
> +		 * enforcing. This would be purely cosmetic.
>  		 */
>  		spin_unlock(&pinned_root_spinlock);
>  		check_pinning_enforcement(pinned_root);
> @@ -161,7 +161,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>  	}
>  
>  	if (IS_ERR_OR_NULL(pinned_root) || load_root != pinned_root) {
> -		if (unlikely(!enabled)) {
> +		if (unlikely(!enforcing)) {
>  			report_load(origin, file, "pinning-ignored");
>  			return 0;
>  		}
> @@ -186,10 +186,11 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
>  
>  void __init loadpin_add_hooks(void)
>  {
> -	pr_info("ready to pin (currently %sabled)", enabled ? "en" : "dis");
> +	pr_info("ready to pin (currently %senforcing)\n",
> +		enforcing ? "" : "not ");
>  	security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
>  }
>  
>  /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
> -module_param(enabled, int, 0);
> -MODULE_PARM_DESC(enabled, "Pin module/firmware loading (default: true)");
> +module_param(enforcing, int, 0);
> +MODULE_PARM_DESC(enforcing, "Enforce module/firmware pinning");
> 


-- 
~Randy

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce"
  2018-10-02  1:06   ` Randy Dunlap
@ 2018-10-02  1:06     ` Randy Dunlap
  2018-10-02  4:47     ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: Randy Dunlap @ 2018-10-02  1:06 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On 10/1/18 5:54 PM, Kees Cook wrote:
> LoadPin's "enable" setting is really about enforcement, not whether
> or not the LSM is using LSM hooks. Instead, split this out so that LSM
> enabling can be logically distinct from whether enforcement is happening
> (for example, the pinning happens when the LSM is enabled, but the pin
> is only checked when "enforce" is set). This allows LoadPin to continue

ISTB:             when "enforcing" is set).  ??

> to operate sanely in test environments once LSM enable/disable is
> centrally handled (i.e. we want LoadPin to be enabled separately from
> its enforcement).
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> Reviewed-by: John Johansen <john.johansen@canonical.com>
> ---
>  security/loadpin/Kconfig   |  4 ++--
>  security/loadpin/loadpin.c | 21 +++++++++++----------
>  2 files changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/security/loadpin/Kconfig b/security/loadpin/Kconfig
> index dd01aa91e521..8653608a3693 100644
> --- a/security/loadpin/Kconfig
> +++ b/security/loadpin/Kconfig
> @@ -10,10 +10,10 @@ config SECURITY_LOADPIN
>  	  have a root filesystem backed by a read-only device such as
>  	  dm-verity or a CDROM.
>  
> -config SECURITY_LOADPIN_ENABLED
> +config SECURITY_LOADPIN_ENFORCING
>  	bool "Enforce LoadPin at boot"
>  	depends on SECURITY_LOADPIN
>  	help
>  	  If selected, LoadPin will enforce pinning at boot. If not
>  	  selected, it can be enabled at boot with the kernel parameter
> -	  "loadpin.enabled=1".
> +	  "loadpin.enforcing=1".
> diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
> index 0716af28808a..d8a68a6f6fef 100644
> --- a/security/loadpin/loadpin.c
> +++ b/security/loadpin/loadpin.c
> @@ -44,7 +44,7 @@ static void report_load(const char *origin, struct file *file, char *operation)
>  	kfree(pathname);
>  }
>  
> -static int enabled = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENABLED);
> +static int enforcing = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCING);
>  static struct super_block *pinned_root;
>  static DEFINE_SPINLOCK(pinned_root_spinlock);
>  
> @@ -60,8 +60,8 @@ static struct ctl_path loadpin_sysctl_path[] = {
>  
>  static struct ctl_table loadpin_sysctl_table[] = {
>  	{
> -		.procname       = "enabled",
> -		.data           = &enabled,
> +		.procname       = "enforcing",
> +		.data           = &enforcing,
>  		.maxlen         = sizeof(int),
>  		.mode           = 0644,
>  		.proc_handler   = proc_dointvec_minmax,
> @@ -97,7 +97,7 @@ static void check_pinning_enforcement(struct super_block *mnt_sb)
>  					   loadpin_sysctl_table))
>  			pr_notice("sysctl registration failed!\n");
>  		else
> -			pr_info("load pinning can be disabled.\n");
> +			pr_info("enforcement can be disabled.\n");
>  	} else
>  		pr_info("load pinning engaged.\n");
>  }
> @@ -128,7 +128,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>  
>  	/* This handles the older init_module API that has a NULL file. */
>  	if (!file) {
> -		if (!enabled) {
> +		if (!enforcing) {
>  			report_load(origin, NULL, "old-api-pinning-ignored");
>  			return 0;
>  		}
> @@ -151,7 +151,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>  		 * Unlock now since it's only pinned_root we care about.
>  		 * In the worst case, we will (correctly) report pinning
>  		 * failures before we have announced that pinning is
> -		 * enabled. This would be purely cosmetic.
> +		 * enforcing. This would be purely cosmetic.
>  		 */
>  		spin_unlock(&pinned_root_spinlock);
>  		check_pinning_enforcement(pinned_root);
> @@ -161,7 +161,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>  	}
>  
>  	if (IS_ERR_OR_NULL(pinned_root) || load_root != pinned_root) {
> -		if (unlikely(!enabled)) {
> +		if (unlikely(!enforcing)) {
>  			report_load(origin, file, "pinning-ignored");
>  			return 0;
>  		}
> @@ -186,10 +186,11 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
>  
>  void __init loadpin_add_hooks(void)
>  {
> -	pr_info("ready to pin (currently %sabled)", enabled ? "en" : "dis");
> +	pr_info("ready to pin (currently %senforcing)\n",
> +		enforcing ? "" : "not ");
>  	security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
>  }
>  
>  /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
> -module_param(enabled, int, 0);
> -MODULE_PARM_DESC(enabled, "Pin module/firmware loading (default: true)");
> +module_param(enforcing, int, 0);
> +MODULE_PARM_DESC(enforcing, "Enforce module/firmware pinning");
> 


-- 
~Randy

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic
  2018-10-02  0:54 ` [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic Kees Cook
  2018-10-02  0:54   ` Kees Cook
@ 2018-10-02  1:18   ` Randy Dunlap
  2018-10-02  1:18     ` Randy Dunlap
  2018-10-02  4:49     ` Kees Cook
  1 sibling, 2 replies; 184+ messages in thread
From: Randy Dunlap @ 2018-10-02  1:18 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On 10/1/18 5:54 PM, Kees Cook wrote:
> Prior to this patch, default "enable" behavior was unchanged: SELinux
> and AppArmor were controlled separately from the centralized control
> defined by CONFIG_LSM_ENABLE and "lsm.enable=...". This changes the
> logic to give all control over to the central logic.
> 
> Instead of allowing SELinux and AppArmor to override the central LSM
> enabling logic, by having separate CONFIG and boot parameters, this
> forces all "enable" variables to disabled, then enables any listed in
> the CONFIG_LSM_ENABLE and "lsm.enable=..." settings, and finally disables
> any listed in "lsm.disable=...".
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  .../admin-guide/kernel-parameters.txt         |  6 ++--
>  include/linux/lsm_hooks.h                     |  2 +-
>  security/security.c                           | 32 +++++++------------
>  3 files changed, 15 insertions(+), 25 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 67c90985d2b8..f646cfab5613 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2279,14 +2279,12 @@
>  	lsm.disable=lsm1,...,lsmN
>  			[SECURITY] Comma-separated list of LSMs to disable
>  			at boot time. This overrides "lsm.enable=",

better:			              This overrides "lsm.enable=" and

> -			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and boot
> -			parameters.
> +			CONFIG_LSM_ENABLE.
>  
>  	lsm.enable=lsm1,...,lsmN
>  			[SECURITY] Comma-separated list of LSMs to enable
>  			at boot time. This overrides any omissions from
> -			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
> -			boot parameters.
> +			CONFIG_LSM_ENABLE.
>  
>  	machvec=	[IA-64] Force the use of a particular machine-vector
>  			(machvec) in a generic kernel.


-- 
~Randy

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic
  2018-10-02  1:18   ` Randy Dunlap
@ 2018-10-02  1:18     ` Randy Dunlap
  2018-10-02  4:49     ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: Randy Dunlap @ 2018-10-02  1:18 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On 10/1/18 5:54 PM, Kees Cook wrote:
> Prior to this patch, default "enable" behavior was unchanged: SELinux
> and AppArmor were controlled separately from the centralized control
> defined by CONFIG_LSM_ENABLE and "lsm.enable=...". This changes the
> logic to give all control over to the central logic.
> 
> Instead of allowing SELinux and AppArmor to override the central LSM
> enabling logic, by having separate CONFIG and boot parameters, this
> forces all "enable" variables to disabled, then enables any listed in
> the CONFIG_LSM_ENABLE and "lsm.enable=..." settings, and finally disables
> any listed in "lsm.disable=...".
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  .../admin-guide/kernel-parameters.txt         |  6 ++--
>  include/linux/lsm_hooks.h                     |  2 +-
>  security/security.c                           | 32 +++++++------------
>  3 files changed, 15 insertions(+), 25 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 67c90985d2b8..f646cfab5613 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2279,14 +2279,12 @@
>  	lsm.disable=lsm1,...,lsmN
>  			[SECURITY] Comma-separated list of LSMs to disable
>  			at boot time. This overrides "lsm.enable=",

better:			              This overrides "lsm.enable=" and

> -			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and boot
> -			parameters.
> +			CONFIG_LSM_ENABLE.
>  
>  	lsm.enable=lsm1,...,lsmN
>  			[SECURITY] Comma-separated list of LSMs to enable
>  			at boot time. This overrides any omissions from
> -			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
> -			boot parameters.
> +			CONFIG_LSM_ENABLE.
>  
>  	machvec=	[IA-64] Force the use of a particular machine-vector
>  			(machvec) in a generic kernel.


-- 
~Randy

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce"
  2018-10-02  1:06   ` Randy Dunlap
  2018-10-02  1:06     ` Randy Dunlap
@ 2018-10-02  4:47     ` Kees Cook
  2018-10-02  4:47       ` Kees Cook
  1 sibling, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  4:47 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: James Morris, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 6:06 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 10/1/18 5:54 PM, Kees Cook wrote:
>> LoadPin's "enable" setting is really about enforcement, not whether
>> or not the LSM is using LSM hooks. Instead, split this out so that LSM
>> enabling can be logically distinct from whether enforcement is happening
>> (for example, the pinning happens when the LSM is enabled, but the pin
>> is only checked when "enforce" is set). This allows LoadPin to continue
>
> ISTB:             when "enforcing" is set).  ??

Whoops, thanks. And I need to do s/enable/enabled/ in the log. I'll fix this up.

-Kees

>
>> to operate sanely in test environments once LSM enable/disable is
>> centrally handled (i.e. we want LoadPin to be enabled separately from
>> its enforcement).
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
>> Reviewed-by: John Johansen <john.johansen@canonical.com>
>> ---
>>  security/loadpin/Kconfig   |  4 ++--
>>  security/loadpin/loadpin.c | 21 +++++++++++----------
>>  2 files changed, 13 insertions(+), 12 deletions(-)
>>
>> diff --git a/security/loadpin/Kconfig b/security/loadpin/Kconfig
>> index dd01aa91e521..8653608a3693 100644
>> --- a/security/loadpin/Kconfig
>> +++ b/security/loadpin/Kconfig
>> @@ -10,10 +10,10 @@ config SECURITY_LOADPIN
>>         have a root filesystem backed by a read-only device such as
>>         dm-verity or a CDROM.
>>
>> -config SECURITY_LOADPIN_ENABLED
>> +config SECURITY_LOADPIN_ENFORCING
>>       bool "Enforce LoadPin at boot"
>>       depends on SECURITY_LOADPIN
>>       help
>>         If selected, LoadPin will enforce pinning at boot. If not
>>         selected, it can be enabled at boot with the kernel parameter
>> -       "loadpin.enabled=1".
>> +       "loadpin.enforcing=1".
>> diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
>> index 0716af28808a..d8a68a6f6fef 100644
>> --- a/security/loadpin/loadpin.c
>> +++ b/security/loadpin/loadpin.c
>> @@ -44,7 +44,7 @@ static void report_load(const char *origin, struct file *file, char *operation)
>>       kfree(pathname);
>>  }
>>
>> -static int enabled = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENABLED);
>> +static int enforcing = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCING);
>>  static struct super_block *pinned_root;
>>  static DEFINE_SPINLOCK(pinned_root_spinlock);
>>
>> @@ -60,8 +60,8 @@ static struct ctl_path loadpin_sysctl_path[] = {
>>
>>  static struct ctl_table loadpin_sysctl_table[] = {
>>       {
>> -             .procname       = "enabled",
>> -             .data           = &enabled,
>> +             .procname       = "enforcing",
>> +             .data           = &enforcing,
>>               .maxlen         = sizeof(int),
>>               .mode           = 0644,
>>               .proc_handler   = proc_dointvec_minmax,
>> @@ -97,7 +97,7 @@ static void check_pinning_enforcement(struct super_block *mnt_sb)
>>                                          loadpin_sysctl_table))
>>                       pr_notice("sysctl registration failed!\n");
>>               else
>> -                     pr_info("load pinning can be disabled.\n");
>> +                     pr_info("enforcement can be disabled.\n");
>>       } else
>>               pr_info("load pinning engaged.\n");
>>  }
>> @@ -128,7 +128,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>>
>>       /* This handles the older init_module API that has a NULL file. */
>>       if (!file) {
>> -             if (!enabled) {
>> +             if (!enforcing) {
>>                       report_load(origin, NULL, "old-api-pinning-ignored");
>>                       return 0;
>>               }
>> @@ -151,7 +151,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>>                * Unlock now since it's only pinned_root we care about.
>>                * In the worst case, we will (correctly) report pinning
>>                * failures before we have announced that pinning is
>> -              * enabled. This would be purely cosmetic.
>> +              * enforcing. This would be purely cosmetic.
>>                */
>>               spin_unlock(&pinned_root_spinlock);
>>               check_pinning_enforcement(pinned_root);
>> @@ -161,7 +161,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>>       }
>>
>>       if (IS_ERR_OR_NULL(pinned_root) || load_root != pinned_root) {
>> -             if (unlikely(!enabled)) {
>> +             if (unlikely(!enforcing)) {
>>                       report_load(origin, file, "pinning-ignored");
>>                       return 0;
>>               }
>> @@ -186,10 +186,11 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
>>
>>  void __init loadpin_add_hooks(void)
>>  {
>> -     pr_info("ready to pin (currently %sabled)", enabled ? "en" : "dis");
>> +     pr_info("ready to pin (currently %senforcing)\n",
>> +             enforcing ? "" : "not ");
>>       security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
>>  }
>>
>>  /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
>> -module_param(enabled, int, 0);
>> -MODULE_PARM_DESC(enabled, "Pin module/firmware loading (default: true)");
>> +module_param(enforcing, int, 0);
>> +MODULE_PARM_DESC(enforcing, "Enforce module/firmware pinning");
>>
>
>
> --
> ~Randy



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce"
  2018-10-02  4:47     ` Kees Cook
@ 2018-10-02  4:47       ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  4:47 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: James Morris, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 6:06 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 10/1/18 5:54 PM, Kees Cook wrote:
>> LoadPin's "enable" setting is really about enforcement, not whether
>> or not the LSM is using LSM hooks. Instead, split this out so that LSM
>> enabling can be logically distinct from whether enforcement is happening
>> (for example, the pinning happens when the LSM is enabled, but the pin
>> is only checked when "enforce" is set). This allows LoadPin to continue
>
> ISTB:             when "enforcing" is set).  ??

Whoops, thanks. And I need to do s/enable/enabled/ in the log. I'll fix this up.

-Kees

>
>> to operate sanely in test environments once LSM enable/disable is
>> centrally handled (i.e. we want LoadPin to be enabled separately from
>> its enforcement).
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
>> Reviewed-by: John Johansen <john.johansen@canonical.com>
>> ---
>>  security/loadpin/Kconfig   |  4 ++--
>>  security/loadpin/loadpin.c | 21 +++++++++++----------
>>  2 files changed, 13 insertions(+), 12 deletions(-)
>>
>> diff --git a/security/loadpin/Kconfig b/security/loadpin/Kconfig
>> index dd01aa91e521..8653608a3693 100644
>> --- a/security/loadpin/Kconfig
>> +++ b/security/loadpin/Kconfig
>> @@ -10,10 +10,10 @@ config SECURITY_LOADPIN
>>         have a root filesystem backed by a read-only device such as
>>         dm-verity or a CDROM.
>>
>> -config SECURITY_LOADPIN_ENABLED
>> +config SECURITY_LOADPIN_ENFORCING
>>       bool "Enforce LoadPin at boot"
>>       depends on SECURITY_LOADPIN
>>       help
>>         If selected, LoadPin will enforce pinning at boot. If not
>>         selected, it can be enabled at boot with the kernel parameter
>> -       "loadpin.enabled=1".
>> +       "loadpin.enforcing=1".
>> diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
>> index 0716af28808a..d8a68a6f6fef 100644
>> --- a/security/loadpin/loadpin.c
>> +++ b/security/loadpin/loadpin.c
>> @@ -44,7 +44,7 @@ static void report_load(const char *origin, struct file *file, char *operation)
>>       kfree(pathname);
>>  }
>>
>> -static int enabled = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENABLED);
>> +static int enforcing = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCING);
>>  static struct super_block *pinned_root;
>>  static DEFINE_SPINLOCK(pinned_root_spinlock);
>>
>> @@ -60,8 +60,8 @@ static struct ctl_path loadpin_sysctl_path[] = {
>>
>>  static struct ctl_table loadpin_sysctl_table[] = {
>>       {
>> -             .procname       = "enabled",
>> -             .data           = &enabled,
>> +             .procname       = "enforcing",
>> +             .data           = &enforcing,
>>               .maxlen         = sizeof(int),
>>               .mode           = 0644,
>>               .proc_handler   = proc_dointvec_minmax,
>> @@ -97,7 +97,7 @@ static void check_pinning_enforcement(struct super_block *mnt_sb)
>>                                          loadpin_sysctl_table))
>>                       pr_notice("sysctl registration failed!\n");
>>               else
>> -                     pr_info("load pinning can be disabled.\n");
>> +                     pr_info("enforcement can be disabled.\n");
>>       } else
>>               pr_info("load pinning engaged.\n");
>>  }
>> @@ -128,7 +128,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>>
>>       /* This handles the older init_module API that has a NULL file. */
>>       if (!file) {
>> -             if (!enabled) {
>> +             if (!enforcing) {
>>                       report_load(origin, NULL, "old-api-pinning-ignored");
>>                       return 0;
>>               }
>> @@ -151,7 +151,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>>                * Unlock now since it's only pinned_root we care about.
>>                * In the worst case, we will (correctly) report pinning
>>                * failures before we have announced that pinning is
>> -              * enabled. This would be purely cosmetic.
>> +              * enforcing. This would be purely cosmetic.
>>                */
>>               spin_unlock(&pinned_root_spinlock);
>>               check_pinning_enforcement(pinned_root);
>> @@ -161,7 +161,7 @@ static int loadpin_read_file(struct file *file, enum kernel_read_file_id id)
>>       }
>>
>>       if (IS_ERR_OR_NULL(pinned_root) || load_root != pinned_root) {
>> -             if (unlikely(!enabled)) {
>> +             if (unlikely(!enforcing)) {
>>                       report_load(origin, file, "pinning-ignored");
>>                       return 0;
>>               }
>> @@ -186,10 +186,11 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
>>
>>  void __init loadpin_add_hooks(void)
>>  {
>> -     pr_info("ready to pin (currently %sabled)", enabled ? "en" : "dis");
>> +     pr_info("ready to pin (currently %senforcing)\n",
>> +             enforcing ? "" : "not ");
>>       security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
>>  }
>>
>>  /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
>> -module_param(enabled, int, 0);
>> -MODULE_PARM_DESC(enabled, "Pin module/firmware loading (default: true)");
>> +module_param(enforcing, int, 0);
>> +MODULE_PARM_DESC(enforcing, "Enforce module/firmware pinning");
>>
>
>
> --
> ~Randy



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic
  2018-10-02  1:18   ` Randy Dunlap
  2018-10-02  1:18     ` Randy Dunlap
@ 2018-10-02  4:49     ` Kees Cook
  2018-10-02  4:49       ` Kees Cook
  1 sibling, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02  4:49 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: James Morris, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 6:18 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 10/1/18 5:54 PM, Kees Cook wrote:
>> Prior to this patch, default "enable" behavior was unchanged: SELinux
>> and AppArmor were controlled separately from the centralized control
>> defined by CONFIG_LSM_ENABLE and "lsm.enable=...". This changes the
>> logic to give all control over to the central logic.
>>
>> Instead of allowing SELinux and AppArmor to override the central LSM
>> enabling logic, by having separate CONFIG and boot parameters, this
>> forces all "enable" variables to disabled, then enables any listed in
>> the CONFIG_LSM_ENABLE and "lsm.enable=..." settings, and finally disables
>> any listed in "lsm.disable=...".
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>>  .../admin-guide/kernel-parameters.txt         |  6 ++--
>>  include/linux/lsm_hooks.h                     |  2 +-
>>  security/security.c                           | 32 +++++++------------
>>  3 files changed, 15 insertions(+), 25 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 67c90985d2b8..f646cfab5613 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2279,14 +2279,12 @@
>>       lsm.disable=lsm1,...,lsmN
>>                       [SECURITY] Comma-separated list of LSMs to disable
>>                       at boot time. This overrides "lsm.enable=",
>
> better:                               This overrides "lsm.enable=" and

Eek, yes! Thank you. :)

-Kees

>
>> -                     CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and boot
>> -                     parameters.
>> +                     CONFIG_LSM_ENABLE.
>>
>>       lsm.enable=lsm1,...,lsmN
>>                       [SECURITY] Comma-separated list of LSMs to enable
>>                       at boot time. This overrides any omissions from
>> -                     CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
>> -                     boot parameters.
>> +                     CONFIG_LSM_ENABLE.
>>
>>       machvec=        [IA-64] Force the use of a particular machine-vector
>>                       (machvec) in a generic kernel.
>
>
> --
> ~Randy



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic
  2018-10-02  4:49     ` Kees Cook
@ 2018-10-02  4:49       ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02  4:49 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: James Morris, Casey Schaufler, John Johansen, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 6:18 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> On 10/1/18 5:54 PM, Kees Cook wrote:
>> Prior to this patch, default "enable" behavior was unchanged: SELinux
>> and AppArmor were controlled separately from the centralized control
>> defined by CONFIG_LSM_ENABLE and "lsm.enable=...". This changes the
>> logic to give all control over to the central logic.
>>
>> Instead of allowing SELinux and AppArmor to override the central LSM
>> enabling logic, by having separate CONFIG and boot parameters, this
>> forces all "enable" variables to disabled, then enables any listed in
>> the CONFIG_LSM_ENABLE and "lsm.enable=..." settings, and finally disables
>> any listed in "lsm.disable=...".
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>>  .../admin-guide/kernel-parameters.txt         |  6 ++--
>>  include/linux/lsm_hooks.h                     |  2 +-
>>  security/security.c                           | 32 +++++++------------
>>  3 files changed, 15 insertions(+), 25 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 67c90985d2b8..f646cfab5613 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -2279,14 +2279,12 @@
>>       lsm.disable=lsm1,...,lsmN
>>                       [SECURITY] Comma-separated list of LSMs to disable
>>                       at boot time. This overrides "lsm.enable=",
>
> better:                               This overrides "lsm.enable=" and

Eek, yes! Thank you. :)

-Kees

>
>> -                     CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and boot
>> -                     parameters.
>> +                     CONFIG_LSM_ENABLE.
>>
>>       lsm.enable=lsm1,...,lsmN
>>                       [SECURITY] Comma-separated list of LSMs to enable
>>                       at boot time. This overrides any omissions from
>> -                     CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
>> -                     boot parameters.
>> +                     CONFIG_LSM_ENABLE.
>>
>>       machvec=        [IA-64] Force the use of a particular machine-vector
>>                       (machvec) in a generic kernel.
>
>
> --
> ~Randy



-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02  0:54 ` [PATCH security-next v4 23/32] selinux: " Kees Cook
  2018-10-02  0:54   ` Kees Cook
@ 2018-10-02 12:12   ` Paul Moore
  2018-10-02 12:12     ` Paul Moore
  2018-10-02 13:42     ` Stephen Smalley
  1 sibling, 2 replies; 184+ messages in thread
From: Paul Moore @ 2018-10-02 12:12 UTC (permalink / raw)
  To: keescook
  Cc: James Morris, casey, john.johansen, penguin-kernel,
	Stephen Smalley, casey.schaufler, linux-security-module, corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
> "lsm.enable=...", this removes the LSM-specific enabling logic from
> SELinux.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  .../admin-guide/kernel-parameters.txt         |  9 ------
>  security/selinux/Kconfig                      | 29 -------------------
>  security/selinux/hooks.c                      | 15 +---------
>  3 files changed, 1 insertion(+), 52 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index cf963febebb0..0d10ab3d020e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4045,15 +4045,6 @@
>                         loaded. An invalid security module name will be treated
>                         as if no module has been chosen.
>
> -       selinux=        [SELINUX] Disable or enable SELinux at boot time.
> -                       Format: { "0" | "1" }
> -                       See security/selinux/Kconfig help text.
> -                       0 -- disable.
> -                       1 -- enable.
> -                       Default value is set via kernel config option.
> -                       If enabled at boot time, /selinux/disable can be used
> -                       later to disable prior to initial policy load.

No comments yet on the rest of the patchset, but the subject line of
this patch caught my eye and I wanted to comment quickly on this one
...

Not a fan unfortunately.

Much like the SELinux bits under /proc/self/attr, this is a user
visible thing which has made its way into a lot of docs, scripts, and
minds; I believe removing it would be a big mistake.

>         serialnumber    [BUGS=X86-32]
>
>         shapers=        [NET]
> diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
> index 8af7a690eb40..86936528a0bb 100644
> --- a/security/selinux/Kconfig
> +++ b/security/selinux/Kconfig
> @@ -8,35 +8,6 @@ config SECURITY_SELINUX
>           You will also need a policy configuration and a labeled filesystem.
>           If you are unsure how to answer this question, answer N.
>
> -config SECURITY_SELINUX_BOOTPARAM
> -       bool "NSA SELinux boot parameter"
> -       depends on SECURITY_SELINUX
> -       default n
> -       help
> -         This option adds a kernel parameter 'selinux', which allows SELinux
> -         to be disabled at boot.  If this option is selected, SELinux
> -         functionality can be disabled with selinux=0 on the kernel
> -         command line.  The purpose of this option is to allow a single
> -         kernel image to be distributed with SELinux built in, but not
> -         necessarily enabled.
> -
> -         If you are unsure how to answer this question, answer N.
> -
> -config SECURITY_SELINUX_BOOTPARAM_VALUE
> -       int "NSA SELinux boot parameter default value"
> -       depends on SECURITY_SELINUX_BOOTPARAM
> -       range 0 1
> -       default 1
> -       help
> -         This option sets the default value for the kernel parameter
> -         'selinux', which allows SELinux to be disabled at boot.  If this
> -         option is set to 0 (zero), the SELinux kernel parameter will
> -         default to 0, disabling SELinux at bootup.  If this option is
> -         set to 1 (one), the SELinux kernel parameter will default to 1,
> -         enabling SELinux at bootup.
> -
> -         If you are unsure how to answer this question, answer 1.
> -
>  config SECURITY_SELINUX_DISABLE
>         bool "NSA SELinux runtime disable"
>         depends on SECURITY_SELINUX
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 71a10fedecb3..8f5eea097612 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -120,20 +120,7 @@ __setup("enforcing=", enforcing_setup);
>  #define selinux_enforcing_boot 1
>  #endif
>
> -#ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
> -int selinux_enabled = CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE;
> -
> -static int __init selinux_enabled_setup(char *str)
> -{
> -       unsigned long enabled;
> -       if (!kstrtoul(str, 0, &enabled))
> -               selinux_enabled = enabled ? 1 : 0;
> -       return 1;
> -}
> -__setup("selinux=", selinux_enabled_setup);
> -#else
> -int selinux_enabled = 1;
> -#endif
> +int selinux_enabled __lsm_ro_after_init;
>
>  static unsigned int selinux_checkreqprot_boot =
>         CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE;
> --
> 2.17.1
>


-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 12:12   ` Paul Moore
@ 2018-10-02 12:12     ` Paul Moore
  2018-10-02 13:42     ` Stephen Smalley
  1 sibling, 0 replies; 184+ messages in thread
From: Paul Moore @ 2018-10-02 12:12 UTC (permalink / raw)
  To: keescook
  Cc: James Morris, casey, john.johansen, penguin-kernel,
	Stephen Smalley, casey.schaufler, linux-security-module, corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
> "lsm.enable=...", this removes the LSM-specific enabling logic from
> SELinux.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  .../admin-guide/kernel-parameters.txt         |  9 ------
>  security/selinux/Kconfig                      | 29 -------------------
>  security/selinux/hooks.c                      | 15 +---------
>  3 files changed, 1 insertion(+), 52 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index cf963febebb0..0d10ab3d020e 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -4045,15 +4045,6 @@
>                         loaded. An invalid security module name will be treated
>                         as if no module has been chosen.
>
> -       selinux=        [SELINUX] Disable or enable SELinux at boot time.
> -                       Format: { "0" | "1" }
> -                       See security/selinux/Kconfig help text.
> -                       0 -- disable.
> -                       1 -- enable.
> -                       Default value is set via kernel config option.
> -                       If enabled at boot time, /selinux/disable can be used
> -                       later to disable prior to initial policy load.

No comments yet on the rest of the patchset, but the subject line of
this patch caught my eye and I wanted to comment quickly on this one
...

Not a fan unfortunately.

Much like the SELinux bits under /proc/self/attr, this is a user
visible thing which has made its way into a lot of docs, scripts, and
minds; I believe removing it would be a big mistake.

>         serialnumber    [BUGS=X86-32]
>
>         shapers=        [NET]
> diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
> index 8af7a690eb40..86936528a0bb 100644
> --- a/security/selinux/Kconfig
> +++ b/security/selinux/Kconfig
> @@ -8,35 +8,6 @@ config SECURITY_SELINUX
>           You will also need a policy configuration and a labeled filesystem.
>           If you are unsure how to answer this question, answer N.
>
> -config SECURITY_SELINUX_BOOTPARAM
> -       bool "NSA SELinux boot parameter"
> -       depends on SECURITY_SELINUX
> -       default n
> -       help
> -         This option adds a kernel parameter 'selinux', which allows SELinux
> -         to be disabled at boot.  If this option is selected, SELinux
> -         functionality can be disabled with selinux=0 on the kernel
> -         command line.  The purpose of this option is to allow a single
> -         kernel image to be distributed with SELinux built in, but not
> -         necessarily enabled.
> -
> -         If you are unsure how to answer this question, answer N.
> -
> -config SECURITY_SELINUX_BOOTPARAM_VALUE
> -       int "NSA SELinux boot parameter default value"
> -       depends on SECURITY_SELINUX_BOOTPARAM
> -       range 0 1
> -       default 1
> -       help
> -         This option sets the default value for the kernel parameter
> -         'selinux', which allows SELinux to be disabled at boot.  If this
> -         option is set to 0 (zero), the SELinux kernel parameter will
> -         default to 0, disabling SELinux at bootup.  If this option is
> -         set to 1 (one), the SELinux kernel parameter will default to 1,
> -         enabling SELinux at bootup.
> -
> -         If you are unsure how to answer this question, answer 1.
> -
>  config SECURITY_SELINUX_DISABLE
>         bool "NSA SELinux runtime disable"
>         depends on SECURITY_SELINUX
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 71a10fedecb3..8f5eea097612 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -120,20 +120,7 @@ __setup("enforcing=", enforcing_setup);
>  #define selinux_enforcing_boot 1
>  #endif
>
> -#ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
> -int selinux_enabled = CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE;
> -
> -static int __init selinux_enabled_setup(char *str)
> -{
> -       unsigned long enabled;
> -       if (!kstrtoul(str, 0, &enabled))
> -               selinux_enabled = enabled ? 1 : 0;
> -       return 1;
> -}
> -__setup("selinux=", selinux_enabled_setup);
> -#else
> -int selinux_enabled = 1;
> -#endif
> +int selinux_enabled __lsm_ro_after_init;
>
>  static unsigned int selinux_checkreqprot_boot =
>         CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE;
> --
> 2.17.1
>


-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 12:12   ` Paul Moore
  2018-10-02 12:12     ` Paul Moore
@ 2018-10-02 13:42     ` Stephen Smalley
  2018-10-02 13:42       ` Stephen Smalley
  2018-10-02 14:44       ` Kees Cook
  1 sibling, 2 replies; 184+ messages in thread
From: Stephen Smalley @ 2018-10-02 13:42 UTC (permalink / raw)
  To: Paul Moore, keescook
  Cc: James Morris, casey, john.johansen, penguin-kernel,
	casey.schaufler, linux-security-module, corbet, linux-doc,
	linux-arch, linux-kernel

On 10/02/2018 08:12 AM, Paul Moore wrote:
> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>> "lsm.enable=...", this removes the LSM-specific enabling logic from
>> SELinux.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>>   .../admin-guide/kernel-parameters.txt         |  9 ------
>>   security/selinux/Kconfig                      | 29 -------------------
>>   security/selinux/hooks.c                      | 15 +---------
>>   3 files changed, 1 insertion(+), 52 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index cf963febebb0..0d10ab3d020e 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -4045,15 +4045,6 @@
>>                          loaded. An invalid security module name will be treated
>>                          as if no module has been chosen.
>>
>> -       selinux=        [SELINUX] Disable or enable SELinux at boot time.
>> -                       Format: { "0" | "1" }
>> -                       See security/selinux/Kconfig help text.
>> -                       0 -- disable.
>> -                       1 -- enable.
>> -                       Default value is set via kernel config option.
>> -                       If enabled at boot time, /selinux/disable can be used
>> -                       later to disable prior to initial policy load.
> 
> No comments yet on the rest of the patchset, but the subject line of
> this patch caught my eye and I wanted to comment quickly on this one
> ...
> 
> Not a fan unfortunately.
> 
> Much like the SELinux bits under /proc/self/attr, this is a user
> visible thing which has made its way into a lot of docs, scripts, and
> minds; I believe removing it would be a big mistake.

Yes, we can't suddenly break existing systems that had selinux=0 in 
their grub config.  We have to retain the support.

> 
>>          serialnumber    [BUGS=X86-32]
>>
>>          shapers=        [NET]
>> diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
>> index 8af7a690eb40..86936528a0bb 100644
>> --- a/security/selinux/Kconfig
>> +++ b/security/selinux/Kconfig
>> @@ -8,35 +8,6 @@ config SECURITY_SELINUX
>>            You will also need a policy configuration and a labeled filesystem.
>>            If you are unsure how to answer this question, answer N.
>>
>> -config SECURITY_SELINUX_BOOTPARAM
>> -       bool "NSA SELinux boot parameter"
>> -       depends on SECURITY_SELINUX
>> -       default n
>> -       help
>> -         This option adds a kernel parameter 'selinux', which allows SELinux
>> -         to be disabled at boot.  If this option is selected, SELinux
>> -         functionality can be disabled with selinux=0 on the kernel
>> -         command line.  The purpose of this option is to allow a single
>> -         kernel image to be distributed with SELinux built in, but not
>> -         necessarily enabled.
>> -
>> -         If you are unsure how to answer this question, answer N.
>> -
>> -config SECURITY_SELINUX_BOOTPARAM_VALUE
>> -       int "NSA SELinux boot parameter default value"
>> -       depends on SECURITY_SELINUX_BOOTPARAM
>> -       range 0 1
>> -       default 1
>> -       help
>> -         This option sets the default value for the kernel parameter
>> -         'selinux', which allows SELinux to be disabled at boot.  If this
>> -         option is set to 0 (zero), the SELinux kernel parameter will
>> -         default to 0, disabling SELinux at bootup.  If this option is
>> -         set to 1 (one), the SELinux kernel parameter will default to 1,
>> -         enabling SELinux at bootup.
>> -
>> -         If you are unsure how to answer this question, answer 1.
>> -
>>   config SECURITY_SELINUX_DISABLE
>>          bool "NSA SELinux runtime disable"
>>          depends on SECURITY_SELINUX
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 71a10fedecb3..8f5eea097612 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -120,20 +120,7 @@ __setup("enforcing=", enforcing_setup);
>>   #define selinux_enforcing_boot 1
>>   #endif
>>
>> -#ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
>> -int selinux_enabled = CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE;
>> -
>> -static int __init selinux_enabled_setup(char *str)
>> -{
>> -       unsigned long enabled;
>> -       if (!kstrtoul(str, 0, &enabled))
>> -               selinux_enabled = enabled ? 1 : 0;
>> -       return 1;
>> -}
>> -__setup("selinux=", selinux_enabled_setup);
>> -#else
>> -int selinux_enabled = 1;
>> -#endif
>> +int selinux_enabled __lsm_ro_after_init;
>>
>>   static unsigned int selinux_checkreqprot_boot =
>>          CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE;
>> --
>> 2.17.1
>>
> 
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 13:42     ` Stephen Smalley
@ 2018-10-02 13:42       ` Stephen Smalley
  2018-10-02 14:44       ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: Stephen Smalley @ 2018-10-02 13:42 UTC (permalink / raw)
  To: Paul Moore, keescook
  Cc: James Morris, casey, john.johansen, penguin-kernel,
	casey.schaufler, linux-security-module, corbet, linux-doc,
	linux-arch, linux-kernel

On 10/02/2018 08:12 AM, Paul Moore wrote:
> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>> "lsm.enable=...", this removes the LSM-specific enabling logic from
>> SELinux.
>>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>>   .../admin-guide/kernel-parameters.txt         |  9 ------
>>   security/selinux/Kconfig                      | 29 -------------------
>>   security/selinux/hooks.c                      | 15 +---------
>>   3 files changed, 1 insertion(+), 52 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index cf963febebb0..0d10ab3d020e 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -4045,15 +4045,6 @@
>>                          loaded. An invalid security module name will be treated
>>                          as if no module has been chosen.
>>
>> -       selinux=        [SELINUX] Disable or enable SELinux at boot time.
>> -                       Format: { "0" | "1" }
>> -                       See security/selinux/Kconfig help text.
>> -                       0 -- disable.
>> -                       1 -- enable.
>> -                       Default value is set via kernel config option.
>> -                       If enabled at boot time, /selinux/disable can be used
>> -                       later to disable prior to initial policy load.
> 
> No comments yet on the rest of the patchset, but the subject line of
> this patch caught my eye and I wanted to comment quickly on this one
> ...
> 
> Not a fan unfortunately.
> 
> Much like the SELinux bits under /proc/self/attr, this is a user
> visible thing which has made its way into a lot of docs, scripts, and
> minds; I believe removing it would be a big mistake.

Yes, we can't suddenly break existing systems that had selinux=0 in 
their grub config.  We have to retain the support.

> 
>>          serialnumber    [BUGS=X86-32]
>>
>>          shapers=        [NET]
>> diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
>> index 8af7a690eb40..86936528a0bb 100644
>> --- a/security/selinux/Kconfig
>> +++ b/security/selinux/Kconfig
>> @@ -8,35 +8,6 @@ config SECURITY_SELINUX
>>            You will also need a policy configuration and a labeled filesystem.
>>            If you are unsure how to answer this question, answer N.
>>
>> -config SECURITY_SELINUX_BOOTPARAM
>> -       bool "NSA SELinux boot parameter"
>> -       depends on SECURITY_SELINUX
>> -       default n
>> -       help
>> -         This option adds a kernel parameter 'selinux', which allows SELinux
>> -         to be disabled at boot.  If this option is selected, SELinux
>> -         functionality can be disabled with selinux=0 on the kernel
>> -         command line.  The purpose of this option is to allow a single
>> -         kernel image to be distributed with SELinux built in, but not
>> -         necessarily enabled.
>> -
>> -         If you are unsure how to answer this question, answer N.
>> -
>> -config SECURITY_SELINUX_BOOTPARAM_VALUE
>> -       int "NSA SELinux boot parameter default value"
>> -       depends on SECURITY_SELINUX_BOOTPARAM
>> -       range 0 1
>> -       default 1
>> -       help
>> -         This option sets the default value for the kernel parameter
>> -         'selinux', which allows SELinux to be disabled at boot.  If this
>> -         option is set to 0 (zero), the SELinux kernel parameter will
>> -         default to 0, disabling SELinux at bootup.  If this option is
>> -         set to 1 (one), the SELinux kernel parameter will default to 1,
>> -         enabling SELinux at bootup.
>> -
>> -         If you are unsure how to answer this question, answer 1.
>> -
>>   config SECURITY_SELINUX_DISABLE
>>          bool "NSA SELinux runtime disable"
>>          depends on SECURITY_SELINUX
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 71a10fedecb3..8f5eea097612 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -120,20 +120,7 @@ __setup("enforcing=", enforcing_setup);
>>   #define selinux_enforcing_boot 1
>>   #endif
>>
>> -#ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
>> -int selinux_enabled = CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE;
>> -
>> -static int __init selinux_enabled_setup(char *str)
>> -{
>> -       unsigned long enabled;
>> -       if (!kstrtoul(str, 0, &enabled))
>> -               selinux_enabled = enabled ? 1 : 0;
>> -       return 1;
>> -}
>> -__setup("selinux=", selinux_enabled_setup);
>> -#else
>> -int selinux_enabled = 1;
>> -#endif
>> +int selinux_enabled __lsm_ro_after_init;
>>
>>   static unsigned int selinux_checkreqprot_boot =
>>          CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE;
>> --
>> 2.17.1
>>
> 
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 13:42     ` Stephen Smalley
  2018-10-02 13:42       ` Stephen Smalley
@ 2018-10-02 14:44       ` Kees Cook
  2018-10-02 14:44         ` Kees Cook
  2018-10-02 14:58         ` Stephen Smalley
  1 sibling, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 14:44 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Paul Moore, James Morris, Casey Schaufler, John Johansen,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 10/02/2018 08:12 AM, Paul Moore wrote:
>>
>> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
>>>
>>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>>> "lsm.enable=...", this removes the LSM-specific enabling logic from
>>> SELinux.
>>>
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> ---
>>>   .../admin-guide/kernel-parameters.txt         |  9 ------
>>>   security/selinux/Kconfig                      | 29 -------------------
>>>   security/selinux/hooks.c                      | 15 +---------
>>>   3 files changed, 1 insertion(+), 52 deletions(-)
>>>
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>> b/Documentation/admin-guide/kernel-parameters.txt
>>> index cf963febebb0..0d10ab3d020e 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -4045,15 +4045,6 @@
>>>                          loaded. An invalid security module name will be
>>> treated
>>>                          as if no module has been chosen.
>>>
>>> -       selinux=        [SELINUX] Disable or enable SELinux at boot time.
>>> -                       Format: { "0" | "1" }
>>> -                       See security/selinux/Kconfig help text.
>>> -                       0 -- disable.
>>> -                       1 -- enable.
>>> -                       Default value is set via kernel config option.
>>> -                       If enabled at boot time, /selinux/disable can be
>>> used
>>> -                       later to disable prior to initial policy load.
>>
>>
>> No comments yet on the rest of the patchset, but the subject line of
>> this patch caught my eye and I wanted to comment quickly on this one
>> ...
>>
>> Not a fan unfortunately.
>>
>> Much like the SELinux bits under /proc/self/attr, this is a user
>> visible thing which has made its way into a lot of docs, scripts, and
>> minds; I believe removing it would be a big mistake.
>
>
> Yes, we can't suddenly break existing systems that had selinux=0 in their
> grub config.  We have to retain the support.

Is it okay to only support selinux=0 (instead of also selinux=1)?

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 14:44       ` Kees Cook
@ 2018-10-02 14:44         ` Kees Cook
  2018-10-02 14:58         ` Stephen Smalley
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 14:44 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Paul Moore, James Morris, Casey Schaufler, John Johansen,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 10/02/2018 08:12 AM, Paul Moore wrote:
>>
>> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
>>>
>>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>>> "lsm.enable=...", this removes the LSM-specific enabling logic from
>>> SELinux.
>>>
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> ---
>>>   .../admin-guide/kernel-parameters.txt         |  9 ------
>>>   security/selinux/Kconfig                      | 29 -------------------
>>>   security/selinux/hooks.c                      | 15 +---------
>>>   3 files changed, 1 insertion(+), 52 deletions(-)
>>>
>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>> b/Documentation/admin-guide/kernel-parameters.txt
>>> index cf963febebb0..0d10ab3d020e 100644
>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>> @@ -4045,15 +4045,6 @@
>>>                          loaded. An invalid security module name will be
>>> treated
>>>                          as if no module has been chosen.
>>>
>>> -       selinux=        [SELINUX] Disable or enable SELinux at boot time.
>>> -                       Format: { "0" | "1" }
>>> -                       See security/selinux/Kconfig help text.
>>> -                       0 -- disable.
>>> -                       1 -- enable.
>>> -                       Default value is set via kernel config option.
>>> -                       If enabled at boot time, /selinux/disable can be
>>> used
>>> -                       later to disable prior to initial policy load.
>>
>>
>> No comments yet on the rest of the patchset, but the subject line of
>> this patch caught my eye and I wanted to comment quickly on this one
>> ...
>>
>> Not a fan unfortunately.
>>
>> Much like the SELinux bits under /proc/self/attr, this is a user
>> visible thing which has made its way into a lot of docs, scripts, and
>> minds; I believe removing it would be a big mistake.
>
>
> Yes, we can't suddenly break existing systems that had selinux=0 in their
> grub config.  We have to retain the support.

Is it okay to only support selinux=0 (instead of also selinux=1)?

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 14:44       ` Kees Cook
  2018-10-02 14:44         ` Kees Cook
@ 2018-10-02 14:58         ` Stephen Smalley
  2018-10-02 14:58           ` Stephen Smalley
                             ` (2 more replies)
  1 sibling, 3 replies; 184+ messages in thread
From: Stephen Smalley @ 2018-10-02 14:58 UTC (permalink / raw)
  To: Kees Cook
  Cc: Paul Moore, James Morris, Casey Schaufler, John Johansen,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 10:44 AM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 10/02/2018 08:12 AM, Paul Moore wrote:
>>>
>>> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
>>>>
>>>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>>>> "lsm.enable=...", this removes the LSM-specific enabling logic from
>>>> SELinux.
>>>>
>>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>>> ---
>>>>    .../admin-guide/kernel-parameters.txt         |  9 ------
>>>>    security/selinux/Kconfig                      | 29 -------------------
>>>>    security/selinux/hooks.c                      | 15 +---------
>>>>    3 files changed, 1 insertion(+), 52 deletions(-)
>>>>
>>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>>> b/Documentation/admin-guide/kernel-parameters.txt
>>>> index cf963febebb0..0d10ab3d020e 100644
>>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>>> @@ -4045,15 +4045,6 @@
>>>>                           loaded. An invalid security module name will be
>>>> treated
>>>>                           as if no module has been chosen.
>>>>
>>>> -       selinux=        [SELINUX] Disable or enable SELinux at boot time.
>>>> -                       Format: { "0" | "1" }
>>>> -                       See security/selinux/Kconfig help text.
>>>> -                       0 -- disable.
>>>> -                       1 -- enable.
>>>> -                       Default value is set via kernel config option.
>>>> -                       If enabled at boot time, /selinux/disable can be
>>>> used
>>>> -                       later to disable prior to initial policy load.
>>>
>>>
>>> No comments yet on the rest of the patchset, but the subject line of
>>> this patch caught my eye and I wanted to comment quickly on this one
>>> ...
>>>
>>> Not a fan unfortunately.
>>>
>>> Much like the SELinux bits under /proc/self/attr, this is a user
>>> visible thing which has made its way into a lot of docs, scripts, and
>>> minds; I believe removing it would be a big mistake.
>>
>>
>> Yes, we can't suddenly break existing systems that had selinux=0 in their
>> grub config.  We have to retain the support.
> 
> Is it okay to only support selinux=0 (instead of also selinux=1)?

For Fedora/RHEL kernels, selinux=1 would be redundant since it is the 
default.  However, in other distros where SELinux is not the default, I 
think they have documented selinux=1 as the way to enable SELinux.  So 
users may be relying on that as well. I don't think we can safely drop 
support for either one.  Sorry.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 14:58         ` Stephen Smalley
@ 2018-10-02 14:58           ` Stephen Smalley
  2018-10-02 16:33           ` Jordan Glover
  2018-10-02 16:34           ` Kees Cook
  2 siblings, 0 replies; 184+ messages in thread
From: Stephen Smalley @ 2018-10-02 14:58 UTC (permalink / raw)
  To: Kees Cook
  Cc: Paul Moore, James Morris, Casey Schaufler, John Johansen,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 10:44 AM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 10/02/2018 08:12 AM, Paul Moore wrote:
>>>
>>> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
>>>>
>>>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>>>> "lsm.enable=...", this removes the LSM-specific enabling logic from
>>>> SELinux.
>>>>
>>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>>> ---
>>>>    .../admin-guide/kernel-parameters.txt         |  9 ------
>>>>    security/selinux/Kconfig                      | 29 -------------------
>>>>    security/selinux/hooks.c                      | 15 +---------
>>>>    3 files changed, 1 insertion(+), 52 deletions(-)
>>>>
>>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>>> b/Documentation/admin-guide/kernel-parameters.txt
>>>> index cf963febebb0..0d10ab3d020e 100644
>>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>>> @@ -4045,15 +4045,6 @@
>>>>                           loaded. An invalid security module name will be
>>>> treated
>>>>                           as if no module has been chosen.
>>>>
>>>> -       selinux=        [SELINUX] Disable or enable SELinux at boot time.
>>>> -                       Format: { "0" | "1" }
>>>> -                       See security/selinux/Kconfig help text.
>>>> -                       0 -- disable.
>>>> -                       1 -- enable.
>>>> -                       Default value is set via kernel config option.
>>>> -                       If enabled at boot time, /selinux/disable can be
>>>> used
>>>> -                       later to disable prior to initial policy load.
>>>
>>>
>>> No comments yet on the rest of the patchset, but the subject line of
>>> this patch caught my eye and I wanted to comment quickly on this one
>>> ...
>>>
>>> Not a fan unfortunately.
>>>
>>> Much like the SELinux bits under /proc/self/attr, this is a user
>>> visible thing which has made its way into a lot of docs, scripts, and
>>> minds; I believe removing it would be a big mistake.
>>
>>
>> Yes, we can't suddenly break existing systems that had selinux=0 in their
>> grub config.  We have to retain the support.
> 
> Is it okay to only support selinux=0 (instead of also selinux=1)?

For Fedora/RHEL kernels, selinux=1 would be redundant since it is the 
default.  However, in other distros where SELinux is not the default, I 
think they have documented selinux=1 as the way to enable SELinux.  So 
users may be relying on that as well. I don't think we can safely drop 
support for either one.  Sorry.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 14:58         ` Stephen Smalley
  2018-10-02 14:58           ` Stephen Smalley
@ 2018-10-02 16:33           ` Jordan Glover
  2018-10-02 16:33             ` Jordan Glover
  2018-10-02 16:54             ` Kees Cook
  2018-10-02 16:34           ` Kees Cook
  2 siblings, 2 replies; 184+ messages in thread
From: Jordan Glover @ 2018-10-02 16:33 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Kees Cook, Paul Moore, James Morris, Casey Schaufler,
	John Johansen, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, October 2, 2018 4:57 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 10/02/2018 10:44 AM, Kees Cook wrote:
>
> > On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley sds@tycho.nsa.gov wrote:
> >
> > > On 10/02/2018 08:12 AM, Paul Moore wrote:
> > >
> > > > On Mon, Oct 1, 2018 at 9:04 PM Kees Cook keescook@chromium.org wrote:
> > > >
> > > > > Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
> > > > > "lsm.enable=...", this removes the LSM-specific enabling logic from
> > > > > SELinux.
> > > > >
> > > > > Signed-off-by: Kees Cook keescook@chromium.org
> > > > >
> > > > > -----------------------------------------------
> > > > >
> > > > > .../admin-guide/kernel-parameters.txt | 9 ------
> > > > > security/selinux/Kconfig | 29 -------------------
> > > > > security/selinux/hooks.c | 15 +---------
> > > > > 3 files changed, 1 insertion(+), 52 deletions(-)
> > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > > > > b/Documentation/admin-guide/kernel-parameters.txt
> > > > > index cf963febebb0..0d10ab3d020e 100644
> > > > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > > > @@ -4045,15 +4045,6 @@
> > > > > loaded. An invalid security module name will be
> > > > > treated
> > > > > as if no module has been chosen.
> > > > >
> > > > > -         selinux=        [SELINUX] Disable or enable SELinux at boot time.
> > > > >
> > > > >
> > > > > -                         Format: { "0" | "1" }
> > > > >
> > > > >
> > > > > -                         See security/selinux/Kconfig help text.
> > > > >
> > > > >
> > > > > -                         0 -- disable.
> > > > >
> > > > >
> > > > > -                         1 -- enable.
> > > > >
> > > > >
> > > > > -                         Default value is set via kernel config option.
> > > > >
> > > > >
> > > > > -                         If enabled at boot time, /selinux/disable can be
> > > > >
> > > > >
> > > > >
> > > > > used
> > > > >
> > > > > -                         later to disable prior to initial policy load.
> > > > >
> > > > >
> > > >
> > > > No comments yet on the rest of the patchset, but the subject line of
> > > > this patch caught my eye and I wanted to comment quickly on this one
> > > > ...
> > > > Not a fan unfortunately.
> > > > Much like the SELinux bits under /proc/self/attr, this is a user
> > > > visible thing which has made its way into a lot of docs, scripts, and
> > > > minds; I believe removing it would be a big mistake.
> > >
> > > Yes, we can't suddenly break existing systems that had selinux=0 in their
> > > grub config. We have to retain the support.
> >
> > Is it okay to only support selinux=0 (instead of also selinux=1)?
>
> For Fedora/RHEL kernels, selinux=1 would be redundant since it is the
> default. However, in other distros where SELinux is not the default, I
> think they have documented selinux=1 as the way to enable SELinux. So
> users may be relying on that as well. I don't think we can safely drop
> support for either one. Sorry.

It's always documented as: "selinux=1 security=selinux" so security= should
still do the job and selinux=1 become no-op, no?

Jordan

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 16:33           ` Jordan Glover
@ 2018-10-02 16:33             ` Jordan Glover
  2018-10-02 16:54             ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: Jordan Glover @ 2018-10-02 16:33 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Kees Cook, Paul Moore, James Morris, Casey Schaufler,
	John Johansen, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, October 2, 2018 4:57 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On 10/02/2018 10:44 AM, Kees Cook wrote:
>
> > On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley sds@tycho.nsa.gov wrote:
> >
> > > On 10/02/2018 08:12 AM, Paul Moore wrote:
> > >
> > > > On Mon, Oct 1, 2018 at 9:04 PM Kees Cook keescook@chromium.org wrote:
> > > >
> > > > > Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
> > > > > "lsm.enable=...", this removes the LSM-specific enabling logic from
> > > > > SELinux.
> > > > >
> > > > > Signed-off-by: Kees Cook keescook@chromium.org
> > > > >
> > > > > -----------------------------------------------
> > > > >
> > > > > .../admin-guide/kernel-parameters.txt | 9 ------
> > > > > security/selinux/Kconfig | 29 -------------------
> > > > > security/selinux/hooks.c | 15 +---------
> > > > > 3 files changed, 1 insertion(+), 52 deletions(-)
> > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > > > > b/Documentation/admin-guide/kernel-parameters.txt
> > > > > index cf963febebb0..0d10ab3d020e 100644
> > > > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > > > @@ -4045,15 +4045,6 @@
> > > > > loaded. An invalid security module name will be
> > > > > treated
> > > > > as if no module has been chosen.
> > > > >
> > > > > -         selinux=        [SELINUX] Disable or enable SELinux at boot time.
> > > > >
> > > > >
> > > > > -                         Format: { "0" | "1" }
> > > > >
> > > > >
> > > > > -                         See security/selinux/Kconfig help text.
> > > > >
> > > > >
> > > > > -                         0 -- disable.
> > > > >
> > > > >
> > > > > -                         1 -- enable.
> > > > >
> > > > >
> > > > > -                         Default value is set via kernel config option.
> > > > >
> > > > >
> > > > > -                         If enabled at boot time, /selinux/disable can be
> > > > >
> > > > >
> > > > >
> > > > > used
> > > > >
> > > > > -                         later to disable prior to initial policy load.
> > > > >
> > > > >
> > > >
> > > > No comments yet on the rest of the patchset, but the subject line of
> > > > this patch caught my eye and I wanted to comment quickly on this one
> > > > ...
> > > > Not a fan unfortunately.
> > > > Much like the SELinux bits under /proc/self/attr, this is a user
> > > > visible thing which has made its way into a lot of docs, scripts, and
> > > > minds; I believe removing it would be a big mistake.
> > >
> > > Yes, we can't suddenly break existing systems that had selinux=0 in their
> > > grub config. We have to retain the support.
> >
> > Is it okay to only support selinux=0 (instead of also selinux=1)?
>
> For Fedora/RHEL kernels, selinux=1 would be redundant since it is the
> default. However, in other distros where SELinux is not the default, I
> think they have documented selinux=1 as the way to enable SELinux. So
> users may be relying on that as well. I don't think we can safely drop
> support for either one. Sorry.

It's always documented as: "selinux=1 security=selinux" so security= should
still do the job and selinux=1 become no-op, no?

Jordan

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 14:58         ` Stephen Smalley
  2018-10-02 14:58           ` Stephen Smalley
  2018-10-02 16:33           ` Jordan Glover
@ 2018-10-02 16:34           ` Kees Cook
  2018-10-02 16:34             ` Kees Cook
  2 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02 16:34 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Paul Moore, James Morris, Casey Schaufler, John Johansen,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Tue, Oct 2, 2018 at 7:58 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 10/02/2018 10:44 AM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>
>>> On 10/02/2018 08:12 AM, Paul Moore wrote:
>>>>
>>>>
>>>> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
>>>>>
>>>>>
>>>>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>>>>> "lsm.enable=...", this removes the LSM-specific enabling logic from
>>>>> SELinux.
>>>>>
>>>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>>>> ---
>>>>>    .../admin-guide/kernel-parameters.txt         |  9 ------
>>>>>    security/selinux/Kconfig                      | 29
>>>>> -------------------
>>>>>    security/selinux/hooks.c                      | 15 +---------
>>>>>    3 files changed, 1 insertion(+), 52 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>>>> b/Documentation/admin-guide/kernel-parameters.txt
>>>>> index cf963febebb0..0d10ab3d020e 100644
>>>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>>>> @@ -4045,15 +4045,6 @@
>>>>>                           loaded. An invalid security module name will
>>>>> be
>>>>> treated
>>>>>                           as if no module has been chosen.
>>>>>
>>>>> -       selinux=        [SELINUX] Disable or enable SELinux at boot
>>>>> time.
>>>>> -                       Format: { "0" | "1" }
>>>>> -                       See security/selinux/Kconfig help text.
>>>>> -                       0 -- disable.
>>>>> -                       1 -- enable.
>>>>> -                       Default value is set via kernel config option.
>>>>> -                       If enabled at boot time, /selinux/disable can
>>>>> be
>>>>> used
>>>>> -                       later to disable prior to initial policy load.
>>>>
>>>>
>>>>
>>>> No comments yet on the rest of the patchset, but the subject line of
>>>> this patch caught my eye and I wanted to comment quickly on this one
>>>> ...
>>>>
>>>> Not a fan unfortunately.
>>>>
>>>> Much like the SELinux bits under /proc/self/attr, this is a user
>>>> visible thing which has made its way into a lot of docs, scripts, and
>>>> minds; I believe removing it would be a big mistake.
>>>
>>>
>>>
>>> Yes, we can't suddenly break existing systems that had selinux=0 in their
>>> grub config.  We have to retain the support.
>>
>>
>> Is it okay to only support selinux=0 (instead of also selinux=1)?
>
>
> For Fedora/RHEL kernels, selinux=1 would be redundant since it is the
> default.  However, in other distros where SELinux is not the default, I
> think they have documented selinux=1 as the way to enable SELinux.  So users
> may be relying on that as well. I don't think we can safely drop support for
> either one.  Sorry.

Okay. How would you like to resolve this? Should SELinux remain
"enable special", and AppArmor is okay to remove the LSM-specific
enabling?

The trouble is with handling CONFIG_LSM_ENABLE vs lsm.enable=... boot
param vs the SELinux bootparam. I.e. CONFIG_LSM_ENABLE is redundant to
SECURITY_SELINUX_BOOTPARAM_VALUE, and selinux= is redundant to
lsm.enable=. Specifically, how should the kernel distinguish between
the four settings?

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 16:34           ` Kees Cook
@ 2018-10-02 16:34             ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 16:34 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Paul Moore, James Morris, Casey Schaufler, John Johansen,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Tue, Oct 2, 2018 at 7:58 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 10/02/2018 10:44 AM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>
>>> On 10/02/2018 08:12 AM, Paul Moore wrote:
>>>>
>>>>
>>>> On Mon, Oct 1, 2018 at 9:04 PM Kees Cook <keescook@chromium.org> wrote:
>>>>>
>>>>>
>>>>> Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and
>>>>> "lsm.enable=...", this removes the LSM-specific enabling logic from
>>>>> SELinux.
>>>>>
>>>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>>>> ---
>>>>>    .../admin-guide/kernel-parameters.txt         |  9 ------
>>>>>    security/selinux/Kconfig                      | 29
>>>>> -------------------
>>>>>    security/selinux/hooks.c                      | 15 +---------
>>>>>    3 files changed, 1 insertion(+), 52 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>>>> b/Documentation/admin-guide/kernel-parameters.txt
>>>>> index cf963febebb0..0d10ab3d020e 100644
>>>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>>>> @@ -4045,15 +4045,6 @@
>>>>>                           loaded. An invalid security module name will
>>>>> be
>>>>> treated
>>>>>                           as if no module has been chosen.
>>>>>
>>>>> -       selinux=        [SELINUX] Disable or enable SELinux at boot
>>>>> time.
>>>>> -                       Format: { "0" | "1" }
>>>>> -                       See security/selinux/Kconfig help text.
>>>>> -                       0 -- disable.
>>>>> -                       1 -- enable.
>>>>> -                       Default value is set via kernel config option.
>>>>> -                       If enabled at boot time, /selinux/disable can
>>>>> be
>>>>> used
>>>>> -                       later to disable prior to initial policy load.
>>>>
>>>>
>>>>
>>>> No comments yet on the rest of the patchset, but the subject line of
>>>> this patch caught my eye and I wanted to comment quickly on this one
>>>> ...
>>>>
>>>> Not a fan unfortunately.
>>>>
>>>> Much like the SELinux bits under /proc/self/attr, this is a user
>>>> visible thing which has made its way into a lot of docs, scripts, and
>>>> minds; I believe removing it would be a big mistake.
>>>
>>>
>>>
>>> Yes, we can't suddenly break existing systems that had selinux=0 in their
>>> grub config.  We have to retain the support.
>>
>>
>> Is it okay to only support selinux=0 (instead of also selinux=1)?
>
>
> For Fedora/RHEL kernels, selinux=1 would be redundant since it is the
> default.  However, in other distros where SELinux is not the default, I
> think they have documented selinux=1 as the way to enable SELinux.  So users
> may be relying on that as well. I don't think we can safely drop support for
> either one.  Sorry.

Okay. How would you like to resolve this? Should SELinux remain
"enable special", and AppArmor is okay to remove the LSM-specific
enabling?

The trouble is with handling CONFIG_LSM_ENABLE vs lsm.enable=... boot
param vs the SELinux bootparam. I.e. CONFIG_LSM_ENABLE is redundant to
SECURITY_SELINUX_BOOTPARAM_VALUE, and selinux= is redundant to
lsm.enable=. Specifically, how should the kernel distinguish between
the four settings?

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 16:33           ` Jordan Glover
  2018-10-02 16:33             ` Jordan Glover
@ 2018-10-02 16:54             ` Kees Cook
  2018-10-02 16:54               ` Kees Cook
                                 ` (2 more replies)
  1 sibling, 3 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 16:54 UTC (permalink / raw)
  To: Jordan Glover
  Cc: Stephen Smalley, Paul Moore, James Morris, Casey Schaufler,
	John Johansen, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
> It's always documented as: "selinux=1 security=selinux" so security= should
> still do the job and selinux=1 become no-op, no?

The v3 patch set worked this way, yes. (The per-LSM enable defaults
were set by the LSM. Only in the case of "lsm.disable=selinux" would
the above stop working.)

John did not like the separation of having two CONFIG and two
bootparams mixing the controls. The v3 resolution rules were:

SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE.
apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE.
apparmor= overrides apparmor.enabled=.
lsm.enable= overrides selinux=.
lsm.enable= overrides apparmor=.
lsm.disable= overrides lsm.enable=.
major LSM _omission_ from security= (if present) overrides lsm.enable.

v4 removed the per-LSM boot params and CONFIGs at John's request, but
Paul and Stephen don't want this for SELinux.

The pieces for reducing conflict with CONFIG_LSM_ENABLE and
lsm.{enable,disable}= were:

1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE.
2- Remove apparmor= and apparmor.enabled=.
3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE.
4- Remove selinux=.

v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too
commonly used. Would 3 be okay for SELinux?

John, with 4 not happening, do you prefer to not have 2 happen?

With CONFIGs removed, then the boot time defaults are controlled by
CONFIG_LSM_ENABLE, but the boot params continue to work as before.
Only the use of the new lsm.enable= and lsm.disable= would override
the per-LSM boot params. This would clean up the build-time CONFIG
weirdness, and leave the existing boot params as before (putting us
functionally in between the v3 and v4 series).

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 16:54             ` Kees Cook
@ 2018-10-02 16:54               ` Kees Cook
  2018-10-02 18:33               ` Stephen Smalley
  2018-10-02 18:57               ` John Johansen
  2 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 16:54 UTC (permalink / raw)
  To: Jordan Glover
  Cc: Stephen Smalley, Paul Moore, James Morris, Casey Schaufler,
	John Johansen, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
> It's always documented as: "selinux=1 security=selinux" so security= should
> still do the job and selinux=1 become no-op, no?

The v3 patch set worked this way, yes. (The per-LSM enable defaults
were set by the LSM. Only in the case of "lsm.disable=selinux" would
the above stop working.)

John did not like the separation of having two CONFIG and two
bootparams mixing the controls. The v3 resolution rules were:

SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE.
apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE.
apparmor= overrides apparmor.enabled=.
lsm.enable= overrides selinux=.
lsm.enable= overrides apparmor=.
lsm.disable= overrides lsm.enable=.
major LSM _omission_ from security= (if present) overrides lsm.enable.

v4 removed the per-LSM boot params and CONFIGs at John's request, but
Paul and Stephen don't want this for SELinux.

The pieces for reducing conflict with CONFIG_LSM_ENABLE and
lsm.{enable,disable}= were:

1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE.
2- Remove apparmor= and apparmor.enabled=.
3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE.
4- Remove selinux=.

v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too
commonly used. Would 3 be okay for SELinux?

John, with 4 not happening, do you prefer to not have 2 happen?

With CONFIGs removed, then the boot time defaults are controlled by
CONFIG_LSM_ENABLE, but the boot params continue to work as before.
Only the use of the new lsm.enable= and lsm.disable= would override
the per-LSM boot params. This would clean up the build-time CONFIG
weirdness, and leave the existing boot params as before (putting us
functionally in between the v3 and v4 series).

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 16:54             ` Kees Cook
  2018-10-02 16:54               ` Kees Cook
@ 2018-10-02 18:33               ` Stephen Smalley
  2018-10-02 18:33                 ` Stephen Smalley
  2018-10-02 19:02                 ` Kees Cook
  2018-10-02 18:57               ` John Johansen
  2 siblings, 2 replies; 184+ messages in thread
From: Stephen Smalley @ 2018-10-02 18:33 UTC (permalink / raw)
  To: Kees Cook, Jordan Glover
  Cc: Paul Moore, James Morris, Casey Schaufler, John Johansen,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 12:54 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
> <Golden_Miller83@protonmail.ch> wrote:
>> It's always documented as: "selinux=1 security=selinux" so security= should
>> still do the job and selinux=1 become no-op, no?
> 
> The v3 patch set worked this way, yes. (The per-LSM enable defaults
> were set by the LSM. Only in the case of "lsm.disable=selinux" would
> the above stop working.)
> 
> John did not like the separation of having two CONFIG and two
> bootparams mixing the controls. The v3 resolution rules were:
> 
> SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
> SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
> selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE.
> apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE.
> apparmor= overrides apparmor.enabled=.
> lsm.enable= overrides selinux=.
> lsm.enable= overrides apparmor=.
> lsm.disable= overrides lsm.enable=.
> major LSM _omission_ from security= (if present) overrides lsm.enable.
> 
> v4 removed the per-LSM boot params and CONFIGs at John's request, but
> Paul and Stephen don't want this for SELinux.
> 
> The pieces for reducing conflict with CONFIG_LSM_ENABLE and
> lsm.{enable,disable}= were:
> 
> 1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE.
> 2- Remove apparmor= and apparmor.enabled=.
> 3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE.
> 4- Remove selinux=.
> 
> v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too
> commonly used. Would 3 be okay for SELinux?

Let's say a user/packager/distro has been building kernels for the past 
14 years (*) with a config that has SECURITY_SELINUX_BOOTPARAM_VALUE=0, 
and now they build a new kernel that includes these patches using that 
same config.  Won't SELinux be enabled by default because 
SECURITY_SELINUX_BOOTPARAM_VALUE is now ignored and LSM_ENABLE defaults 
to all?  Is it ok to require them to specify a new config option to 
preserve old behavior?

(*) how long this config option has been around

> 
> John, with 4 not happening, do you prefer to not have 2 happen?
> 
> With CONFIGs removed, then the boot time defaults are controlled by
> CONFIG_LSM_ENABLE, but the boot params continue to work as before.
> Only the use of the new lsm.enable= and lsm.disable= would override
> the per-LSM boot params. This would clean up the build-time CONFIG
> weirdness, and leave the existing boot params as before (putting us
> functionally in between the v3 and v4 series).
> 
> -Kees
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 18:33               ` Stephen Smalley
@ 2018-10-02 18:33                 ` Stephen Smalley
  2018-10-02 19:02                 ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: Stephen Smalley @ 2018-10-02 18:33 UTC (permalink / raw)
  To: Kees Cook, Jordan Glover
  Cc: Paul Moore, James Morris, Casey Schaufler, John Johansen,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 12:54 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
> <Golden_Miller83@protonmail.ch> wrote:
>> It's always documented as: "selinux=1 security=selinux" so security= should
>> still do the job and selinux=1 become no-op, no?
> 
> The v3 patch set worked this way, yes. (The per-LSM enable defaults
> were set by the LSM. Only in the case of "lsm.disable=selinux" would
> the above stop working.)
> 
> John did not like the separation of having two CONFIG and two
> bootparams mixing the controls. The v3 resolution rules were:
> 
> SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
> SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
> selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE.
> apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE.
> apparmor= overrides apparmor.enabled=.
> lsm.enable= overrides selinux=.
> lsm.enable= overrides apparmor=.
> lsm.disable= overrides lsm.enable=.
> major LSM _omission_ from security= (if present) overrides lsm.enable.
> 
> v4 removed the per-LSM boot params and CONFIGs at John's request, but
> Paul and Stephen don't want this for SELinux.
> 
> The pieces for reducing conflict with CONFIG_LSM_ENABLE and
> lsm.{enable,disable}= were:
> 
> 1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE.
> 2- Remove apparmor= and apparmor.enabled=.
> 3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE.
> 4- Remove selinux=.
> 
> v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too
> commonly used. Would 3 be okay for SELinux?

Let's say a user/packager/distro has been building kernels for the past 
14 years (*) with a config that has SECURITY_SELINUX_BOOTPARAM_VALUE=0, 
and now they build a new kernel that includes these patches using that 
same config.  Won't SELinux be enabled by default because 
SECURITY_SELINUX_BOOTPARAM_VALUE is now ignored and LSM_ENABLE defaults 
to all?  Is it ok to require them to specify a new config option to 
preserve old behavior?

(*) how long this config option has been around

> 
> John, with 4 not happening, do you prefer to not have 2 happen?
> 
> With CONFIGs removed, then the boot time defaults are controlled by
> CONFIG_LSM_ENABLE, but the boot params continue to work as before.
> Only the use of the new lsm.enable= and lsm.disable= would override
> the per-LSM boot params. This would clean up the build-time CONFIG
> weirdness, and leave the existing boot params as before (putting us
> functionally in between the v3 and v4 series).
> 
> -Kees
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 16:54             ` Kees Cook
  2018-10-02 16:54               ` Kees Cook
  2018-10-02 18:33               ` Stephen Smalley
@ 2018-10-02 18:57               ` John Johansen
  2018-10-02 18:57                 ` John Johansen
  2018-10-02 19:17                 ` Kees Cook
  2 siblings, 2 replies; 184+ messages in thread
From: John Johansen @ 2018-10-02 18:57 UTC (permalink / raw)
  To: Kees Cook, Jordan Glover
  Cc: Stephen Smalley, Paul Moore, James Morris, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 09:54 AM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
> <Golden_Miller83@protonmail.ch> wrote:
>> It's always documented as: "selinux=1 security=selinux" so security= should
>> still do the job and selinux=1 become no-op, no?
> 
> The v3 patch set worked this way, yes. (The per-LSM enable defaults
> were set by the LSM. Only in the case of "lsm.disable=selinux" would
> the above stop working.)
> 
> John did not like the separation of having two CONFIG and two

still don't

> bootparams mixing the controls. The v3 resolution rules were:
> 
> SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
> SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
> selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE.
> apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE.
> apparmor= overrides apparmor.enabled=.
> lsm.enable= overrides selinux=.
> lsm.enable= overrides apparmor=.
> lsm.disable= overrides lsm.enable=.
> major LSM _omission_ from security= (if present) overrides lsm.enable.
> 

Yeah I would really like to remove the potential confusion for the
user. The user now has 4 kernel options to play with, and get confused
by

LSM= (I'll count apparmor.enabled= here as well)
security=
lsm.enabled=
lsm.disabled=

I really don't like this, it will be very confusing for users. I also
think an authoritative list of what is enabled is easier for users
than mixing a list of whats enabled with kernel config default
settings.

Under the current scheme

lsm.enabled=selinux

could actually mean selinux,yama,loadpin,something_else are
enabled. If we extend this behavior to when full stacking lands

lsm.enabled=selinux,yama

might mean selinux,yama,apparmor,loadpin,something_else

and what that list is will vary from kernel to kernel, which I think
is harder for the user than the lsm.enabled list being what is
actually enabled at boot

If we have to have multiple kernel parameter, I prefer a behvior where
if you hav conflicting kernel parameters specified

  apparmor=0 lsm.enabled=apparmor

that the conflict is logged and the lsm is left disabled, as I think
it is easier for users to understand than the overrides scheme of v3,
and sans logging of the conflict is effectively what we had in the
past

  apparmor=0 security=apparmor
or
  apparmor=1 security=selinux

would result in apparmor being disabed


That being said I get we have a mess currently, and there really
doesn't seem to be a good way to fix it. I think getting this right
for the user is important enough that I am willing to break current
apparmor userspace api. While apparmor=0 is documented we have also
documented security=X for years and apparmor=0 isn't used too often
so I think we can drop it to help clean this mess up abit.

I am not going to Nak, or block on v3 behavior if that is considered
the best path forward after this discussion/rant.


> v4 removed the per-LSM boot params and CONFIGs at John's request, but
> Paul and Stephen don't want this for SELinux.
> 
> The pieces for reducing conflict with CONFIG_LSM_ENABLE and
> lsm.{enable,disable}= were:
> 
> 1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE.
> 2- Remove apparmor= and apparmor.enabled=.
> 3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE.
> 4- Remove selinux=.
> 
> v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too
> commonly used. Would 3 be okay for SELinux?
> 
> John, with 4 not happening, do you prefer to not have 2 happen?
> 
> With CONFIGs removed, then the boot time defaults are controlled by
> CONFIG_LSM_ENABLE, but the boot params continue to work as before.
> Only the use of the new lsm.enable= and lsm.disable= would override
> the per-LSM boot params. This would clean up the build-time CONFIG
> weirdness, and leave the existing boot params as before (putting us
> functionally in between the v3 and v4 series).
> 
I'm ambivalent. I really want to clean this up but atm it doesn't
really look like 2 is going to provide much of a benefit. If you
think it helps clean this up, do it. Regardless 1 is going to
happen, and I will start updating documentation and try to get
users moving away from using the apparmor= kernel parameter.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 18:57               ` John Johansen
@ 2018-10-02 18:57                 ` John Johansen
  2018-10-02 19:17                 ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-02 18:57 UTC (permalink / raw)
  To: Kees Cook, Jordan Glover
  Cc: Stephen Smalley, Paul Moore, James Morris, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 09:54 AM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
> <Golden_Miller83@protonmail.ch> wrote:
>> It's always documented as: "selinux=1 security=selinux" so security= should
>> still do the job and selinux=1 become no-op, no?
> 
> The v3 patch set worked this way, yes. (The per-LSM enable defaults
> were set by the LSM. Only in the case of "lsm.disable=selinux" would
> the above stop working.)
> 
> John did not like the separation of having two CONFIG and two

still don't

> bootparams mixing the controls. The v3 resolution rules were:
> 
> SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
> SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
> selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE.
> apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE.
> apparmor= overrides apparmor.enabled=.
> lsm.enable= overrides selinux=.
> lsm.enable= overrides apparmor=.
> lsm.disable= overrides lsm.enable=.
> major LSM _omission_ from security= (if present) overrides lsm.enable.
> 

Yeah I would really like to remove the potential confusion for the
user. The user now has 4 kernel options to play with, and get confused
by

LSM= (I'll count apparmor.enabled= here as well)
security=
lsm.enabled=
lsm.disabled=

I really don't like this, it will be very confusing for users. I also
think an authoritative list of what is enabled is easier for users
than mixing a list of whats enabled with kernel config default
settings.

Under the current scheme

lsm.enabled=selinux

could actually mean selinux,yama,loadpin,something_else are
enabled. If we extend this behavior to when full stacking lands

lsm.enabled=selinux,yama

might mean selinux,yama,apparmor,loadpin,something_else

and what that list is will vary from kernel to kernel, which I think
is harder for the user than the lsm.enabled list being what is
actually enabled at boot

If we have to have multiple kernel parameter, I prefer a behvior where
if you hav conflicting kernel parameters specified

  apparmor=0 lsm.enabled=apparmor

that the conflict is logged and the lsm is left disabled, as I think
it is easier for users to understand than the overrides scheme of v3,
and sans logging of the conflict is effectively what we had in the
past

  apparmor=0 security=apparmor
or
  apparmor=1 security=selinux

would result in apparmor being disabed


That being said I get we have a mess currently, and there really
doesn't seem to be a good way to fix it. I think getting this right
for the user is important enough that I am willing to break current
apparmor userspace api. While apparmor=0 is documented we have also
documented security=X for years and apparmor=0 isn't used too often
so I think we can drop it to help clean this mess up abit.

I am not going to Nak, or block on v3 behavior if that is considered
the best path forward after this discussion/rant.


> v4 removed the per-LSM boot params and CONFIGs at John's request, but
> Paul and Stephen don't want this for SELinux.
> 
> The pieces for reducing conflict with CONFIG_LSM_ENABLE and
> lsm.{enable,disable}= were:
> 
> 1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE.
> 2- Remove apparmor= and apparmor.enabled=.
> 3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE.
> 4- Remove selinux=.
> 
> v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too
> commonly used. Would 3 be okay for SELinux?
> 
> John, with 4 not happening, do you prefer to not have 2 happen?
> 
> With CONFIGs removed, then the boot time defaults are controlled by
> CONFIG_LSM_ENABLE, but the boot params continue to work as before.
> Only the use of the new lsm.enable= and lsm.disable= would override
> the per-LSM boot params. This would clean up the build-time CONFIG
> weirdness, and leave the existing boot params as before (putting us
> functionally in between the v3 and v4 series).
> 
I'm ambivalent. I really want to clean this up but atm it doesn't
really look like 2 is going to provide much of a benefit. If you
think it helps clean this up, do it. Regardless 1 is going to
happen, and I will start updating documentation and try to get
users moving away from using the apparmor= kernel parameter.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 18:33               ` Stephen Smalley
  2018-10-02 18:33                 ` Stephen Smalley
@ 2018-10-02 19:02                 ` Kees Cook
  2018-10-02 19:02                   ` Kees Cook
  1 sibling, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02 19:02 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Jordan Glover, Paul Moore, James Morris, Casey Schaufler,
	John Johansen, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 11:33 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 10/02/2018 12:54 PM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
>> <Golden_Miller83@protonmail.ch> wrote:
>>>
>>> It's always documented as: "selinux=1 security=selinux" so security=
>>> should
>>> still do the job and selinux=1 become no-op, no?
>>
>>
>> The v3 patch set worked this way, yes. (The per-LSM enable defaults
>> were set by the LSM. Only in the case of "lsm.disable=selinux" would
>> the above stop working.)
>>
>> John did not like the separation of having two CONFIG and two
>> bootparams mixing the controls. The v3 resolution rules were:
>>
>> SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
>> SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
>> selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE.
>> apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE.
>> apparmor= overrides apparmor.enabled=.
>> lsm.enable= overrides selinux=.
>> lsm.enable= overrides apparmor=.
>> lsm.disable= overrides lsm.enable=.
>> major LSM _omission_ from security= (if present) overrides lsm.enable.
>>
>> v4 removed the per-LSM boot params and CONFIGs at John's request, but
>> Paul and Stephen don't want this for SELinux.
>>
>> The pieces for reducing conflict with CONFIG_LSM_ENABLE and
>> lsm.{enable,disable}= were:
>>
>> 1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE.
>> 2- Remove apparmor= and apparmor.enabled=.
>> 3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE.
>> 4- Remove selinux=.
>>
>> v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too
>> commonly used. Would 3 be okay for SELinux?
>
>
> Let's say a user/packager/distro has been building kernels for the past 14
> years (*) with a config that has SECURITY_SELINUX_BOOTPARAM_VALUE=0, and now
> they build a new kernel that includes these patches using that same config.
> Won't SELinux be enabled by default because SECURITY_SELINUX_BOOTPARAM_VALUE
> is now ignored and LSM_ENABLE defaults to all?  Is it ok to require them to
> specify a new config option to preserve old behavior?

Yes, I think that's fine -- kernel CONFIGs change all the time. System
builders are used to examining these changes.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 19:02                 ` Kees Cook
@ 2018-10-02 19:02                   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 19:02 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Jordan Glover, Paul Moore, James Morris, Casey Schaufler,
	John Johansen, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 11:33 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 10/02/2018 12:54 PM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover
>> <Golden_Miller83@protonmail.ch> wrote:
>>>
>>> It's always documented as: "selinux=1 security=selinux" so security=
>>> should
>>> still do the job and selinux=1 become no-op, no?
>>
>>
>> The v3 patch set worked this way, yes. (The per-LSM enable defaults
>> were set by the LSM. Only in the case of "lsm.disable=selinux" would
>> the above stop working.)
>>
>> John did not like the separation of having two CONFIG and two
>> bootparams mixing the controls. The v3 resolution rules were:
>>
>> SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
>> SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE.
>> selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE.
>> apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE.
>> apparmor= overrides apparmor.enabled=.
>> lsm.enable= overrides selinux=.
>> lsm.enable= overrides apparmor=.
>> lsm.disable= overrides lsm.enable=.
>> major LSM _omission_ from security= (if present) overrides lsm.enable.
>>
>> v4 removed the per-LSM boot params and CONFIGs at John's request, but
>> Paul and Stephen don't want this for SELinux.
>>
>> The pieces for reducing conflict with CONFIG_LSM_ENABLE and
>> lsm.{enable,disable}= were:
>>
>> 1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE.
>> 2- Remove apparmor= and apparmor.enabled=.
>> 3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE.
>> 4- Remove selinux=.
>>
>> v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too
>> commonly used. Would 3 be okay for SELinux?
>
>
> Let's say a user/packager/distro has been building kernels for the past 14
> years (*) with a config that has SECURITY_SELINUX_BOOTPARAM_VALUE=0, and now
> they build a new kernel that includes these patches using that same config.
> Won't SELinux be enabled by default because SECURITY_SELINUX_BOOTPARAM_VALUE
> is now ignored and LSM_ENABLE defaults to all?  Is it ok to require them to
> specify a new config option to preserve old behavior?

Yes, I think that's fine -- kernel CONFIGs change all the time. System
builders are used to examining these changes.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 18:57               ` John Johansen
  2018-10-02 18:57                 ` John Johansen
@ 2018-10-02 19:17                 ` Kees Cook
  2018-10-02 19:17                   ` Kees Cook
                                     ` (2 more replies)
  1 sibling, 3 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 19:17 UTC (permalink / raw)
  To: John Johansen
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, James Morris,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
<john.johansen@canonical.com> wrote:
> Under the current scheme
>
> lsm.enabled=selinux
>
> could actually mean selinux,yama,loadpin,something_else are
> enabled. If we extend this behavior to when full stacking lands
>
> lsm.enabled=selinux,yama
>
> might mean selinux,yama,apparmor,loadpin,something_else
>
> and what that list is will vary from kernel to kernel, which I think
> is harder for the user than the lsm.enabled list being what is
> actually enabled at boot

Ah, I think I missed this in your earlier emails. What you don't like
here is that "lsm.enable=" is additive. You want it to be explicit.

Are you okay with lsm.order= having fallback?

The situation we were trying to solve was with new LSMs getting
implicitly disabled if someone is booting with an explicit list. For
example:

lsm.enable=yama,apparmor

means when "landlock" gets added to the kernel, it will be implicitly disabled.

> If we have to have multiple kernel parameter, I prefer a behvior where
> if you hav conflicting kernel parameters specified
>
>   apparmor=0 lsm.enabled=apparmor
>
> that the conflict is logged and the lsm is left disabled, as I think
> it is easier for users to understand than the overrides scheme of v3,
> and sans logging of the conflict is effectively what we had in the
> past
>
>   apparmor=0 security=apparmor
> or
>   apparmor=1 security=selinux
>
> would result in apparmor being disabed

Okay, so for this part you want per-LSM boot param to have priority
(which seems to match SELinux's concerns), possibly logging the
conflict, but still accepting the apparmor= and selinux= state.
security= would still driving initialization ordering (so I think the
behavior I have in the series would be correct).

> That being said I get we have a mess currently, and there really
> doesn't seem to be a good way to fix it. I think getting this right
> for the user is important enough that I am willing to break current
> apparmor userspace api. While apparmor=0 is documented we have also
> documented security=X for years and apparmor=0 isn't used too often
> so I think we can drop it to help clean this mess up abit.
>
> I am not going to Nak, or block on v3 behavior if that is considered
> the best path forward after this discussion/rant.

I could define CONFIG_LSM_ENABLE as being "additive" to
SECURITY_APPARMOR_BOOTPARAM_VALUE and
SECURITY_SELINUX_BOOTPARAM_VALUE?

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 19:17                 ` Kees Cook
@ 2018-10-02 19:17                   ` Kees Cook
  2018-10-02 19:47                   ` John Johansen
  2018-10-02 22:06                   ` James Morris
  2 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 19:17 UTC (permalink / raw)
  To: John Johansen
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, James Morris,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
<john.johansen@canonical.com> wrote:
> Under the current scheme
>
> lsm.enabled=selinux
>
> could actually mean selinux,yama,loadpin,something_else are
> enabled. If we extend this behavior to when full stacking lands
>
> lsm.enabled=selinux,yama
>
> might mean selinux,yama,apparmor,loadpin,something_else
>
> and what that list is will vary from kernel to kernel, which I think
> is harder for the user than the lsm.enabled list being what is
> actually enabled at boot

Ah, I think I missed this in your earlier emails. What you don't like
here is that "lsm.enable=" is additive. You want it to be explicit.

Are you okay with lsm.order= having fallback?

The situation we were trying to solve was with new LSMs getting
implicitly disabled if someone is booting with an explicit list. For
example:

lsm.enable=yama,apparmor

means when "landlock" gets added to the kernel, it will be implicitly disabled.

> If we have to have multiple kernel parameter, I prefer a behvior where
> if you hav conflicting kernel parameters specified
>
>   apparmor=0 lsm.enabled=apparmor
>
> that the conflict is logged and the lsm is left disabled, as I think
> it is easier for users to understand than the overrides scheme of v3,
> and sans logging of the conflict is effectively what we had in the
> past
>
>   apparmor=0 security=apparmor
> or
>   apparmor=1 security=selinux
>
> would result in apparmor being disabed

Okay, so for this part you want per-LSM boot param to have priority
(which seems to match SELinux's concerns), possibly logging the
conflict, but still accepting the apparmor= and selinux= state.
security= would still driving initialization ordering (so I think the
behavior I have in the series would be correct).

> That being said I get we have a mess currently, and there really
> doesn't seem to be a good way to fix it. I think getting this right
> for the user is important enough that I am willing to break current
> apparmor userspace api. While apparmor=0 is documented we have also
> documented security=X for years and apparmor=0 isn't used too often
> so I think we can drop it to help clean this mess up abit.
>
> I am not going to Nak, or block on v3 behavior if that is considered
> the best path forward after this discussion/rant.

I could define CONFIG_LSM_ENABLE as being "additive" to
SECURITY_APPARMOR_BOOTPARAM_VALUE and
SECURITY_SELINUX_BOOTPARAM_VALUE?

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 19:17                 ` Kees Cook
  2018-10-02 19:17                   ` Kees Cook
@ 2018-10-02 19:47                   ` John Johansen
  2018-10-02 19:47                     ` John Johansen
  2018-10-02 20:29                     ` Kees Cook
  2018-10-02 22:06                   ` James Morris
  2 siblings, 2 replies; 184+ messages in thread
From: John Johansen @ 2018-10-02 19:47 UTC (permalink / raw)
  To: Kees Cook
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, James Morris,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/02/2018 12:17 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> <john.johansen@canonical.com> wrote:
>> Under the current scheme
>>
>> lsm.enabled=selinux
>>
>> could actually mean selinux,yama,loadpin,something_else are
>> enabled. If we extend this behavior to when full stacking lands
>>
>> lsm.enabled=selinux,yama
>>
>> might mean selinux,yama,apparmor,loadpin,something_else
>>
>> and what that list is will vary from kernel to kernel, which I think
>> is harder for the user than the lsm.enabled list being what is
>> actually enabled at boot
> 
> Ah, I think I missed this in your earlier emails. What you don't like
> here is that "lsm.enable=" is additive. You want it to be explicit.
> 
> Are you okay with lsm.order= having fallback?
> 

yeah, if we are going to separate order, fallbacks are fine for
anything that isn't specified.

I am still not convinced that separating order from enablement is
right, but its generally something a user should care about so I can
live with it.

> The situation we were trying to solve was with new LSMs getting
> implicitly disabled if someone is booting with an explicit list. For
> example:
> 
> lsm.enable=yama,apparmor
> 
> means when "landlock" gets added to the kernel, it will be implicitly disabled.
> 

And here is the point of contention, I wouldn't call that implicitly
disabled. The user explicitly selected a set of LSMs to enable. Having
other LSMs enable when they aren't specified is confusing to a user,
as now they have to consider what is enabled by default in the
Kconfig.

I think requiring distros/builders to consider Kconfig options is
fine, but its a lot higher hurdle for regular users.


>> If we have to have multiple kernel parameter, I prefer a behvior where
>> if you hav conflicting kernel parameters specified
>>
>>   apparmor=0 lsm.enabled=apparmor
>>
>> that the conflict is logged and the lsm is left disabled, as I think
>> it is easier for users to understand than the overrides scheme of v3,
>> and sans logging of the conflict is effectively what we had in the
>> past
>>
>>   apparmor=0 security=apparmor
>> or
>>   apparmor=1 security=selinux
>>
>> would result in apparmor being disabed
> 
> Okay, so for this part you want per-LSM boot param to have priority
> (which seems to match SELinux's concerns), possibly logging the

hrmmm I wouldn't call it priority :)

If you look at the above logic its a boolean AND operation. The LSM is
only enabled if $LSM=1 AND security=$LSM all other combinations result
in $LSM being disabled

> conflict, but still accepting the apparmor= and selinux= state.

logging is nice for the user but certainly isn't required and is more
than we are doing today

> security= would still driving initialization ordering (so I think the
> behavior I have in the series would be correct).
> 
>> That being said I get we have a mess currently, and there really
>> doesn't seem to be a good way to fix it. I think getting this right
>> for the user is important enough that I am willing to break current
>> apparmor userspace api. While apparmor=0 is documented we have also
>> documented security=X for years and apparmor=0 isn't used too often
>> so I think we can drop it to help clean this mess up abit.
>>
>> I am not going to Nak, or block on v3 behavior if that is considered
>> the best path forward after this discussion/rant.
> 
> I could define CONFIG_LSM_ENABLE as being "additive" to
> SECURITY_APPARMOR_BOOTPARAM_VALUE and
> SECURITY_SELINUX_BOOTPARAM_VALUE?
> 

Oh sure lets deal with my complaint about too many ways to configure
this beast by adding yet another config option :P

seriously though, please no. That just adds another layer of confusion
even if it is only being foisted on the distro/builder

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 19:47                   ` John Johansen
@ 2018-10-02 19:47                     ` John Johansen
  2018-10-02 20:29                     ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-02 19:47 UTC (permalink / raw)
  To: Kees Cook
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, James Morris,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/02/2018 12:17 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> <john.johansen@canonical.com> wrote:
>> Under the current scheme
>>
>> lsm.enabled=selinux
>>
>> could actually mean selinux,yama,loadpin,something_else are
>> enabled. If we extend this behavior to when full stacking lands
>>
>> lsm.enabled=selinux,yama
>>
>> might mean selinux,yama,apparmor,loadpin,something_else
>>
>> and what that list is will vary from kernel to kernel, which I think
>> is harder for the user than the lsm.enabled list being what is
>> actually enabled at boot
> 
> Ah, I think I missed this in your earlier emails. What you don't like
> here is that "lsm.enable=" is additive. You want it to be explicit.
> 
> Are you okay with lsm.order= having fallback?
> 

yeah, if we are going to separate order, fallbacks are fine for
anything that isn't specified.

I am still not convinced that separating order from enablement is
right, but its generally something a user should care about so I can
live with it.

> The situation we were trying to solve was with new LSMs getting
> implicitly disabled if someone is booting with an explicit list. For
> example:
> 
> lsm.enable=yama,apparmor
> 
> means when "landlock" gets added to the kernel, it will be implicitly disabled.
> 

And here is the point of contention, I wouldn't call that implicitly
disabled. The user explicitly selected a set of LSMs to enable. Having
other LSMs enable when they aren't specified is confusing to a user,
as now they have to consider what is enabled by default in the
Kconfig.

I think requiring distros/builders to consider Kconfig options is
fine, but its a lot higher hurdle for regular users.


>> If we have to have multiple kernel parameter, I prefer a behvior where
>> if you hav conflicting kernel parameters specified
>>
>>   apparmor=0 lsm.enabled=apparmor
>>
>> that the conflict is logged and the lsm is left disabled, as I think
>> it is easier for users to understand than the overrides scheme of v3,
>> and sans logging of the conflict is effectively what we had in the
>> past
>>
>>   apparmor=0 security=apparmor
>> or
>>   apparmor=1 security=selinux
>>
>> would result in apparmor being disabed
> 
> Okay, so for this part you want per-LSM boot param to have priority
> (which seems to match SELinux's concerns), possibly logging the

hrmmm I wouldn't call it priority :)

If you look at the above logic its a boolean AND operation. The LSM is
only enabled if $LSM=1 AND security=$LSM all other combinations result
in $LSM being disabled

> conflict, but still accepting the apparmor= and selinux= state.

logging is nice for the user but certainly isn't required and is more
than we are doing today

> security= would still driving initialization ordering (so I think the
> behavior I have in the series would be correct).
> 
>> That being said I get we have a mess currently, and there really
>> doesn't seem to be a good way to fix it. I think getting this right
>> for the user is important enough that I am willing to break current
>> apparmor userspace api. While apparmor=0 is documented we have also
>> documented security=X for years and apparmor=0 isn't used too often
>> so I think we can drop it to help clean this mess up abit.
>>
>> I am not going to Nak, or block on v3 behavior if that is considered
>> the best path forward after this discussion/rant.
> 
> I could define CONFIG_LSM_ENABLE as being "additive" to
> SECURITY_APPARMOR_BOOTPARAM_VALUE and
> SECURITY_SELINUX_BOOTPARAM_VALUE?
> 

Oh sure lets deal with my complaint about too many ways to configure
this beast by adding yet another config option :P

seriously though, please no. That just adds another layer of confusion
even if it is only being foisted on the distro/builder

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 19:47                   ` John Johansen
  2018-10-02 19:47                     ` John Johansen
@ 2018-10-02 20:29                     ` Kees Cook
  2018-10-02 20:29                       ` Kees Cook
  2018-10-02 21:11                       ` John Johansen
  1 sibling, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 20:29 UTC (permalink / raw)
  To: John Johansen
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, James Morris,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/02/2018 12:17 PM, Kees Cook wrote:
>> I could define CONFIG_LSM_ENABLE as being "additive" to
>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>
> Oh sure lets deal with my complaint about too many ways to configure
> this beast by adding yet another config option :P

This is what v3 already does: SEC...BOOTPARAM_VALUE trumps ...LSM_ENABLE.

> seriously though, please no. That just adds another layer of confusion
> even if it is only being foisted on the distro/builder

You've already sent a patch removing
SECURITY_APPARMOR_BOOTPARAM_VALUE. If SELinux is fine to do that too,
then I think we'll be sorted out. I'll just need to make "lsm.enable="
be an explicit list. (Do you have a problem with "lsm.disable=..." ?)

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 20:29                     ` Kees Cook
@ 2018-10-02 20:29                       ` Kees Cook
  2018-10-02 21:11                       ` John Johansen
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 20:29 UTC (permalink / raw)
  To: John Johansen
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, James Morris,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/02/2018 12:17 PM, Kees Cook wrote:
>> I could define CONFIG_LSM_ENABLE as being "additive" to
>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>
> Oh sure lets deal with my complaint about too many ways to configure
> this beast by adding yet another config option :P

This is what v3 already does: SEC...BOOTPARAM_VALUE trumps ...LSM_ENABLE.

> seriously though, please no. That just adds another layer of confusion
> even if it is only being foisted on the distro/builder

You've already sent a patch removing
SECURITY_APPARMOR_BOOTPARAM_VALUE. If SELinux is fine to do that too,
then I think we'll be sorted out. I'll just need to make "lsm.enable="
be an explicit list. (Do you have a problem with "lsm.disable=..." ?)

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 20:29                     ` Kees Cook
  2018-10-02 20:29                       ` Kees Cook
@ 2018-10-02 21:11                       ` John Johansen
  2018-10-02 21:11                         ` John Johansen
  1 sibling, 1 reply; 184+ messages in thread
From: John Johansen @ 2018-10-02 21:11 UTC (permalink / raw)
  To: Kees Cook
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, James Morris,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/02/2018 01:29 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/02/2018 12:17 PM, Kees Cook wrote:
>>> I could define CONFIG_LSM_ENABLE as being "additive" to
>>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>>
>> Oh sure lets deal with my complaint about too many ways to configure
>> this beast by adding yet another config option :P
> 
> This is what v3 already does: SEC...BOOTPARAM_VALUE trumps ...LSM_ENABLE.
> 
sure but I sent in a patch to kill SECURITY_APPARMOR_BOOTPARAM_VALUE
because I really dislike the extra levels of config and getting rid
of the  SEC..BOOTPARAM_VALUE seems to be the easy way to fix it

Now if only we can convince Paul and Stephen :)

>> seriously though, please no. That just adds another layer of confusion
>> even if it is only being foisted on the distro/builder
> 
> You've already sent a patch removing
> SECURITY_APPARMOR_BOOTPARAM_VALUE. If SELinux is fine to do that too,
> then I think we'll be sorted out. I'll just need to make "lsm.enable="
> be an explicit list. (Do you have a problem with "lsm.disable=..." ?)
> 

why yes, glad you asked

If lsm.enabled is an explicit list lsm.disabled isn't required its a
convenience option that can introduce confusion and conflicts. If
both lsm.enabled and lsm.disabled are being used at the same time.

I realize that some times the convenience of specifying

  lsm.disable=$LSM

is easier than specifying an entire list of what should be enabled
when you just want to disable a single LSM.

I don't think the convenience is worth the potential confusion, but
I don't feel strongly about it and realize others feel the other
way.


tldr: I can live with it, but don't like it if you are asking :)

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 21:11                       ` John Johansen
@ 2018-10-02 21:11                         ` John Johansen
  0 siblings, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-02 21:11 UTC (permalink / raw)
  To: Kees Cook
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, James Morris,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/02/2018 01:29 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/02/2018 12:17 PM, Kees Cook wrote:
>>> I could define CONFIG_LSM_ENABLE as being "additive" to
>>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>>
>> Oh sure lets deal with my complaint about too many ways to configure
>> this beast by adding yet another config option :P
> 
> This is what v3 already does: SEC...BOOTPARAM_VALUE trumps ...LSM_ENABLE.
> 
sure but I sent in a patch to kill SECURITY_APPARMOR_BOOTPARAM_VALUE
because I really dislike the extra levels of config and getting rid
of the  SEC..BOOTPARAM_VALUE seems to be the easy way to fix it

Now if only we can convince Paul and Stephen :)

>> seriously though, please no. That just adds another layer of confusion
>> even if it is only being foisted on the distro/builder
> 
> You've already sent a patch removing
> SECURITY_APPARMOR_BOOTPARAM_VALUE. If SELinux is fine to do that too,
> then I think we'll be sorted out. I'll just need to make "lsm.enable="
> be an explicit list. (Do you have a problem with "lsm.disable=..." ?)
> 

why yes, glad you asked

If lsm.enabled is an explicit list lsm.disabled isn't required its a
convenience option that can introduce confusion and conflicts. If
both lsm.enabled and lsm.disabled are being used at the same time.

I realize that some times the convenience of specifying

  lsm.disable=$LSM

is easier than specifying an entire list of what should be enabled
when you just want to disable a single LSM.

I don't think the convenience is worth the potential confusion, but
I don't feel strongly about it and realize others feel the other
way.


tldr: I can live with it, but don't like it if you are asking :)

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 04/32] LSM: Remove initcall tracing
  2018-10-02  0:54 ` [PATCH security-next v4 04/32] LSM: Remove initcall tracing Kees Cook
  2018-10-02  0:54   ` Kees Cook
@ 2018-10-02 21:14   ` James Morris
  2018-10-02 21:14     ` James Morris
  1 sibling, 1 reply; 184+ messages in thread
From: James Morris @ 2018-10-02 21:14 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> This partially reverts commit 58eacfffc417 ("init, tracing: instrument
> security and console initcall trace events") since security init calls
> are about to no longer resemble regular init calls.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>


Reviewed-by: James Morris <james.morris@microsoft.com>


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 04/32] LSM: Remove initcall tracing
  2018-10-02 21:14   ` James Morris
@ 2018-10-02 21:14     ` James Morris
  0 siblings, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-02 21:14 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> This partially reverts commit 58eacfffc417 ("init, tracing: instrument
> security and console initcall trace events") since security init calls
> are about to no longer resemble regular init calls.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>


Reviewed-by: James Morris <james.morris@microsoft.com>


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 06/32] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
  2018-10-02  0:54 ` [PATCH security-next v4 06/32] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
  2018-10-02  0:54   ` Kees Cook
@ 2018-10-02 21:15   ` James Morris
  2018-10-02 21:15     ` James Morris
  1 sibling, 1 reply; 184+ messages in thread
From: James Morris @ 2018-10-02 21:15 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> Since the struct lsm_info table is not an initcall, we can just move it
> into INIT_DATA like all the other tables.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> Reviewed-by: John Johansen <john.johansen@canonical.com>


Reviewed-by: James Morris <james.morris@microsoft.com>


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 06/32] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
  2018-10-02 21:15   ` James Morris
@ 2018-10-02 21:15     ` James Morris
  0 siblings, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-02 21:15 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> Since the struct lsm_info table is not an initcall, we can just move it
> into INIT_DATA like all the other tables.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> Reviewed-by: John Johansen <john.johansen@canonical.com>


Reviewed-by: James Morris <james.morris@microsoft.com>


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 07/32] LSM: Convert security_initcall() into DEFINE_LSM()
  2018-10-02  0:54 ` [PATCH security-next v4 07/32] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
  2018-10-02  0:54   ` Kees Cook
@ 2018-10-02 21:16   ` James Morris
  2018-10-02 21:16     ` James Morris
  1 sibling, 1 reply; 184+ messages in thread
From: James Morris @ 2018-10-02 21:16 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> Instead of using argument-based initializers, switch to defining the
> contents of struct lsm_info on a per-LSM basis. This also drops
> the final use of the now inaccurate "initcall" naming.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>


Reviewed-by: James Morris <james.morris@microsoft.com>

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 07/32] LSM: Convert security_initcall() into DEFINE_LSM()
  2018-10-02 21:16   ` James Morris
@ 2018-10-02 21:16     ` James Morris
  0 siblings, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-02 21:16 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> Instead of using argument-based initializers, switch to defining the
> contents of struct lsm_info on a per-LSM basis. This also drops
> the final use of the now inaccurate "initcall" naming.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>


Reviewed-by: James Morris <james.morris@microsoft.com>

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 09/32] LSM: Provide init debugging infrastructure
  2018-10-02  0:54 ` [PATCH security-next v4 09/32] LSM: Provide init debugging infrastructure Kees Cook
  2018-10-02  0:54   ` Kees Cook
@ 2018-10-02 21:17   ` James Morris
  2018-10-02 21:17     ` James Morris
  1 sibling, 1 reply; 184+ messages in thread
From: James Morris @ 2018-10-02 21:17 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> Booting with "lsm.debug" will report future details on how LSM ordering
> decisions are being made.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> Reviewed-by: John Johansen <john.johansen@canonical.com>



Reviewed-by: James Morris <james.morris@microsoft.com>


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 09/32] LSM: Provide init debugging infrastructure
  2018-10-02 21:17   ` James Morris
@ 2018-10-02 21:17     ` James Morris
  0 siblings, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-02 21:17 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> Booting with "lsm.debug" will report future details on how LSM ordering
> decisions are being made.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> Reviewed-by: John Johansen <john.johansen@canonical.com>



Reviewed-by: James Morris <james.morris@microsoft.com>


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures
  2018-10-02  0:54 ` [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures Kees Cook
  2018-10-02  0:54   ` Kees Cook
@ 2018-10-02 21:20   ` James Morris
  2018-10-02 21:20     ` James Morris
  2018-10-02 21:38     ` Kees Cook
  1 sibling, 2 replies; 184+ messages in thread
From: James Morris @ 2018-10-02 21:20 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> LSM initialization failures have traditionally been ignored. We should
> at least WARN when something goes wrong.

I guess we could have a boot param which specifies what to do if any LSM 
fails to init, as I think some folks will want to stop execution at that 
point.

Thoughts?


> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> Reviewed-by: John Johansen <john.johansen@canonical.com>
> ---
>  security/security.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/security/security.c b/security/security.c
> index 395f804f6a91..2055af907eba 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -55,10 +55,12 @@ static __initdata bool debug;
>  static void __init major_lsm_init(void)
>  {
>  	struct lsm_info *lsm;
> +	int ret;
>  
>  	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
>  		init_debug("initializing %s\n", lsm->name);
> -		lsm->init();
> +		ret = lsm->init();
> +		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
>  	}
>  }
>  
> 

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures
  2018-10-02 21:20   ` James Morris
@ 2018-10-02 21:20     ` James Morris
  2018-10-02 21:38     ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-02 21:20 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 1 Oct 2018, Kees Cook wrote:

> LSM initialization failures have traditionally been ignored. We should
> at least WARN when something goes wrong.

I guess we could have a boot param which specifies what to do if any LSM 
fails to init, as I think some folks will want to stop execution at that 
point.

Thoughts?


> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> Reviewed-by: John Johansen <john.johansen@canonical.com>
> ---
>  security/security.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/security/security.c b/security/security.c
> index 395f804f6a91..2055af907eba 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -55,10 +55,12 @@ static __initdata bool debug;
>  static void __init major_lsm_init(void)
>  {
>  	struct lsm_info *lsm;
> +	int ret;
>  
>  	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
>  		init_debug("initializing %s\n", lsm->name);
> -		lsm->init();
> +		ret = lsm->init();
> +		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
>  	}
>  }
>  
> 

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures
  2018-10-02 21:20   ` James Morris
  2018-10-02 21:20     ` James Morris
@ 2018-10-02 21:38     ` Kees Cook
  2018-10-02 21:38       ` Kees Cook
  1 sibling, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-02 21:38 UTC (permalink / raw)
  To: James Morris
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Tue, Oct 2, 2018 at 2:20 PM, James Morris <jmorris@namei.org> wrote:
> On Mon, 1 Oct 2018, Kees Cook wrote:
>
>> LSM initialization failures have traditionally been ignored. We should
>> at least WARN when something goes wrong.
>
> I guess we could have a boot param which specifies what to do if any LSM
> fails to init, as I think some folks will want to stop execution at that
> point.
>
> Thoughts?

I'm not opposed, but I won't author it because Linus will yell at me
about introducing a "machine killing" option.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures
  2018-10-02 21:38     ` Kees Cook
@ 2018-10-02 21:38       ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 21:38 UTC (permalink / raw)
  To: James Morris
  Cc: Casey Schaufler, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Tue, Oct 2, 2018 at 2:20 PM, James Morris <jmorris@namei.org> wrote:
> On Mon, 1 Oct 2018, Kees Cook wrote:
>
>> LSM initialization failures have traditionally been ignored. We should
>> at least WARN when something goes wrong.
>
> I guess we could have a boot param which specifies what to do if any LSM
> fails to init, as I think some folks will want to stop execution at that
> point.
>
> Thoughts?

I'm not opposed, but I won't author it because Linus will yell at me
about introducing a "machine killing" option.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 19:17                 ` Kees Cook
  2018-10-02 19:17                   ` Kees Cook
  2018-10-02 19:47                   ` John Johansen
@ 2018-10-02 22:06                   ` James Morris
  2018-10-02 22:06                     ` James Morris
                                       ` (2 more replies)
  2 siblings, 3 replies; 184+ messages in thread
From: James Morris @ 2018-10-02 22:06 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, 2 Oct 2018, Kees Cook wrote:

> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> <john.johansen@canonical.com> wrote:
> > Under the current scheme
> >
> > lsm.enabled=selinux
> >
> > could actually mean selinux,yama,loadpin,something_else are
> > enabled. If we extend this behavior to when full stacking lands
> >
> > lsm.enabled=selinux,yama
> >
> > might mean selinux,yama,apparmor,loadpin,something_else
> >
> > and what that list is will vary from kernel to kernel, which I think
> > is harder for the user than the lsm.enabled list being what is
> > actually enabled at boot
> 
> Ah, I think I missed this in your earlier emails. What you don't like
> here is that "lsm.enable=" is additive. You want it to be explicit.
> 

This is a path to madness.

How about enable flags set ONLY per LSM:

lsm.selinux.enable=x
lsm.apparmor.enable=x

With no lsm.enable, and removing selinux=x and apparmor=x.

Yes this will break existing docs, but they can be updated for newer 
kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from 
kernel X onwards.

Surely distro packages and bootloaders are able to cope with changes to 
kernel parameters?

We can either take a one-time hit now, or build new usability debt, which 
will confuse people forever.


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 22:06                   ` James Morris
@ 2018-10-02 22:06                     ` James Morris
  2018-10-02 23:06                     ` Kees Cook
  2018-10-02 23:28                     ` John Johansen
  2 siblings, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-02 22:06 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, 2 Oct 2018, Kees Cook wrote:

> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
> <john.johansen@canonical.com> wrote:
> > Under the current scheme
> >
> > lsm.enabled=selinux
> >
> > could actually mean selinux,yama,loadpin,something_else are
> > enabled. If we extend this behavior to when full stacking lands
> >
> > lsm.enabled=selinux,yama
> >
> > might mean selinux,yama,apparmor,loadpin,something_else
> >
> > and what that list is will vary from kernel to kernel, which I think
> > is harder for the user than the lsm.enabled list being what is
> > actually enabled at boot
> 
> Ah, I think I missed this in your earlier emails. What you don't like
> here is that "lsm.enable=" is additive. You want it to be explicit.
> 

This is a path to madness.

How about enable flags set ONLY per LSM:

lsm.selinux.enable=x
lsm.apparmor.enable=x

With no lsm.enable, and removing selinux=x and apparmor=x.

Yes this will break existing docs, but they can be updated for newer 
kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from 
kernel X onwards.

Surely distro packages and bootloaders are able to cope with changes to 
kernel parameters?

We can either take a one-time hit now, or build new usability debt, which 
will confuse people forever.


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 22:06                   ` James Morris
  2018-10-02 22:06                     ` James Morris
@ 2018-10-02 23:06                     ` Kees Cook
  2018-10-02 23:06                       ` Kees Cook
  2018-10-02 23:46                       ` John Johansen
  2018-10-02 23:28                     ` John Johansen
  2 siblings, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 23:06 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 3:06 PM, James Morris <jmorris@namei.org> wrote:
> On Tue, 2 Oct 2018, Kees Cook wrote:
>
>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>> <john.johansen@canonical.com> wrote:
>> > Under the current scheme
>> >
>> > lsm.enabled=selinux
>> >
>> > could actually mean selinux,yama,loadpin,something_else are
>> > enabled. If we extend this behavior to when full stacking lands
>> >
>> > lsm.enabled=selinux,yama
>> >
>> > might mean selinux,yama,apparmor,loadpin,something_else
>> >
>> > and what that list is will vary from kernel to kernel, which I think
>> > is harder for the user than the lsm.enabled list being what is
>> > actually enabled at boot
>>
>> Ah, I think I missed this in your earlier emails. What you don't like
>> here is that "lsm.enable=" is additive. You want it to be explicit.
>>
>
> This is a path to madness.
>
> How about enable flags set ONLY per LSM:
>
> lsm.selinux.enable=x
> lsm.apparmor.enable=x
>
> With no lsm.enable, and removing selinux=x and apparmor=x.
>
> Yes this will break existing docs, but they can be updated for newer
> kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from
> kernel X onwards.
>
> Surely distro packages and bootloaders are able to cope with changes to
> kernel parameters?
>
> We can either take a one-time hit now, or build new usability debt, which
> will confuse people forever.

I'd like to avoid this for a few reasons:

- this requires per-LSM plumbing instead of centralized plumbing
  - each LSM needs to have its own CONFIG flag
  - each LSM needs to have its own bootparam flag
- SELinux has explicited stated they do not want to lose selinux=
- this doesn't meet John's goal of having a "single explicit enable list"

I think the current proposal (in the other thread) is likely the
sanest approach:

- Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
- Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
- All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
- Boot time enabling for selinux= and apparmor= remain
- lsm.enable= is explicit: overrides above and omissions are disabled
- maybe include lsm.disable= to disable anything

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 23:06                     ` Kees Cook
@ 2018-10-02 23:06                       ` Kees Cook
  2018-10-02 23:46                       ` John Johansen
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 23:06 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 3:06 PM, James Morris <jmorris@namei.org> wrote:
> On Tue, 2 Oct 2018, Kees Cook wrote:
>
>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>> <john.johansen@canonical.com> wrote:
>> > Under the current scheme
>> >
>> > lsm.enabled=selinux
>> >
>> > could actually mean selinux,yama,loadpin,something_else are
>> > enabled. If we extend this behavior to when full stacking lands
>> >
>> > lsm.enabled=selinux,yama
>> >
>> > might mean selinux,yama,apparmor,loadpin,something_else
>> >
>> > and what that list is will vary from kernel to kernel, which I think
>> > is harder for the user than the lsm.enabled list being what is
>> > actually enabled at boot
>>
>> Ah, I think I missed this in your earlier emails. What you don't like
>> here is that "lsm.enable=" is additive. You want it to be explicit.
>>
>
> This is a path to madness.
>
> How about enable flags set ONLY per LSM:
>
> lsm.selinux.enable=x
> lsm.apparmor.enable=x
>
> With no lsm.enable, and removing selinux=x and apparmor=x.
>
> Yes this will break existing docs, but they can be updated for newer
> kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from
> kernel X onwards.
>
> Surely distro packages and bootloaders are able to cope with changes to
> kernel parameters?
>
> We can either take a one-time hit now, or build new usability debt, which
> will confuse people forever.

I'd like to avoid this for a few reasons:

- this requires per-LSM plumbing instead of centralized plumbing
  - each LSM needs to have its own CONFIG flag
  - each LSM needs to have its own bootparam flag
- SELinux has explicited stated they do not want to lose selinux=
- this doesn't meet John's goal of having a "single explicit enable list"

I think the current proposal (in the other thread) is likely the
sanest approach:

- Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
- Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
- All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
- Boot time enabling for selinux= and apparmor= remain
- lsm.enable= is explicit: overrides above and omissions are disabled
- maybe include lsm.disable= to disable anything

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 22:06                   ` James Morris
  2018-10-02 22:06                     ` James Morris
  2018-10-02 23:06                     ` Kees Cook
@ 2018-10-02 23:28                     ` John Johansen
  2018-10-02 23:28                       ` John Johansen
  2 siblings, 1 reply; 184+ messages in thread
From: John Johansen @ 2018-10-02 23:28 UTC (permalink / raw)
  To: James Morris, Kees Cook
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 03:06 PM, James Morris wrote:
> On Tue, 2 Oct 2018, Kees Cook wrote:
> 
>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>> Under the current scheme
>>>
>>> lsm.enabled=selinux
>>>
>>> could actually mean selinux,yama,loadpin,something_else are
>>> enabled. If we extend this behavior to when full stacking lands
>>>
>>> lsm.enabled=selinux,yama
>>>
>>> might mean selinux,yama,apparmor,loadpin,something_else
>>>
>>> and what that list is will vary from kernel to kernel, which I think
>>> is harder for the user than the lsm.enabled list being what is
>>> actually enabled at boot
>>
>> Ah, I think I missed this in your earlier emails. What you don't like
>> here is that "lsm.enable=" is additive. You want it to be explicit.
>>
> 
> This is a path to madness.
> 
> How about enable flags set ONLY per LSM:
> 
> lsm.selinux.enable=x
> lsm.apparmor.enable=x
> 
why add the lsm. prefix? I think if we go this route
selinux.enable=x
apparmor.enable=x

is a little cleaner

the question then becomes is this easier for users? Doing something
similar to this was discussed earlier but its more tedious to type
each of these out, and since they are separate options they can
get spread out making it easy to miss one when you are changing
your boot options.

I honestly don't think we are going to come to a consensus on what is
best for users because different sets of users have different priorities.
But I do think we need to come up with something cleaner than v3

> With no lsm.enable, and removing selinux=x and apparmor=x.
>
this will break the user api, not just the distro/builder kernel
config. I do think it is probably worth doing, but not everyone agrees.

> Yes this will break existing docs, but they can be updated for newer 
> kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from 
> kernel X onwards.
> 
yes docs can be updated but it does take time to propagate out and their
are always the dozens of blog, and forum posts etc that google will
drag up that won't get updated

> Surely distro packages and bootloaders are able to cope with changes to 
> kernel parameters?
> 
yes, but users who have been taught to add certain incantations to their
kernel parameters find it a lot harder

> We can either take a one-time hit now, or build new usability debt, which 
> will confuse people forever.
> 

I'm not opposed to taking a one-time hit for usability in the future.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 23:28                     ` John Johansen
@ 2018-10-02 23:28                       ` John Johansen
  0 siblings, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-02 23:28 UTC (permalink / raw)
  To: James Morris, Kees Cook
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 03:06 PM, James Morris wrote:
> On Tue, 2 Oct 2018, Kees Cook wrote:
> 
>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>> Under the current scheme
>>>
>>> lsm.enabled=selinux
>>>
>>> could actually mean selinux,yama,loadpin,something_else are
>>> enabled. If we extend this behavior to when full stacking lands
>>>
>>> lsm.enabled=selinux,yama
>>>
>>> might mean selinux,yama,apparmor,loadpin,something_else
>>>
>>> and what that list is will vary from kernel to kernel, which I think
>>> is harder for the user than the lsm.enabled list being what is
>>> actually enabled at boot
>>
>> Ah, I think I missed this in your earlier emails. What you don't like
>> here is that "lsm.enable=" is additive. You want it to be explicit.
>>
> 
> This is a path to madness.
> 
> How about enable flags set ONLY per LSM:
> 
> lsm.selinux.enable=x
> lsm.apparmor.enable=x
> 
why add the lsm. prefix? I think if we go this route
selinux.enable=x
apparmor.enable=x

is a little cleaner

the question then becomes is this easier for users? Doing something
similar to this was discussed earlier but its more tedious to type
each of these out, and since they are separate options they can
get spread out making it easy to miss one when you are changing
your boot options.

I honestly don't think we are going to come to a consensus on what is
best for users because different sets of users have different priorities.
But I do think we need to come up with something cleaner than v3

> With no lsm.enable, and removing selinux=x and apparmor=x.
>
this will break the user api, not just the distro/builder kernel
config. I do think it is probably worth doing, but not everyone agrees.

> Yes this will break existing docs, but they can be updated for newer 
> kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from 
> kernel X onwards.
> 
yes docs can be updated but it does take time to propagate out and their
are always the dozens of blog, and forum posts etc that google will
drag up that won't get updated

> Surely distro packages and bootloaders are able to cope with changes to 
> kernel parameters?
> 
yes, but users who have been taught to add certain incantations to their
kernel parameters find it a lot harder

> We can either take a one-time hit now, or build new usability debt, which 
> will confuse people forever.
> 

I'm not opposed to taking a one-time hit for usability in the future.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 23:06                     ` Kees Cook
  2018-10-02 23:06                       ` Kees Cook
@ 2018-10-02 23:46                       ` John Johansen
  2018-10-02 23:46                         ` John Johansen
                                           ` (2 more replies)
  1 sibling, 3 replies; 184+ messages in thread
From: John Johansen @ 2018-10-02 23:46 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 04:06 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 3:06 PM, James Morris <jmorris@namei.org> wrote:
>> On Tue, 2 Oct 2018, Kees Cook wrote:
>>
>>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>> Under the current scheme
>>>>
>>>> lsm.enabled=selinux
>>>>
>>>> could actually mean selinux,yama,loadpin,something_else are
>>>> enabled. If we extend this behavior to when full stacking lands
>>>>
>>>> lsm.enabled=selinux,yama
>>>>
>>>> might mean selinux,yama,apparmor,loadpin,something_else
>>>>
>>>> and what that list is will vary from kernel to kernel, which I think
>>>> is harder for the user than the lsm.enabled list being what is
>>>> actually enabled at boot
>>>
>>> Ah, I think I missed this in your earlier emails. What you don't like
>>> here is that "lsm.enable=" is additive. You want it to be explicit.
>>>
>>
>> This is a path to madness.
>>
>> How about enable flags set ONLY per LSM:
>>
>> lsm.selinux.enable=x
>> lsm.apparmor.enable=x
>>
>> With no lsm.enable, and removing selinux=x and apparmor=x.
>>
>> Yes this will break existing docs, but they can be updated for newer
>> kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from
>> kernel X onwards.
>>
>> Surely distro packages and bootloaders are able to cope with changes to
>> kernel parameters?
>>
>> We can either take a one-time hit now, or build new usability debt, which
>> will confuse people forever.
> 
> I'd like to avoid this for a few reasons:
> 
> - this requires per-LSM plumbing instead of centralized plumbing
>   - each LSM needs to have its own CONFIG flag
>   - each LSM needs to have its own bootparam flag
> - SELinux has explicited stated they do not want to lose selinux=
> - this doesn't meet John's goal of having a "single explicit enable list"
> 
I can compromise on a single explicit list. My main goal is something that
is consistent and easy for the end user, and I would like to avoid
potential points of confusion if possible.

To me a list like
  lsm.enable=X,Y,Z

is best as a single explicit enable list, and it would be best to avoid
lsm.disable as it just introduces confusion.

I do think per-LSM bootparams looses the advantages of centralization,
and still requires the user to know some Kconfig info but it also gets
rid of the lsm.disable confusion.

With ordering separated out from being enabled there is a certain
cleanness to it. And perhaps most users are looking to enable/disable
a single lsm, instead of specifying exactly what security they want
on their system.

If we were to go this route I would rather drop the lsm. prefix


> I think the current proposal (in the other thread) is likely the
> sanest approach:
> 
> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE

Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
available to be enabled by default at boot.

> - Boot time enabling for selinux= and apparmor= remain
> - lsm.enable= is explicit: overrides above and omissions are disabled
wfm

> - maybe include lsm.disable= to disable anything

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 23:46                       ` John Johansen
@ 2018-10-02 23:46                         ` John Johansen
  2018-10-02 23:54                         ` Kees Cook
  2018-10-03 18:17                         ` James Morris
  2 siblings, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-02 23:46 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 04:06 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 3:06 PM, James Morris <jmorris@namei.org> wrote:
>> On Tue, 2 Oct 2018, Kees Cook wrote:
>>
>>> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>> Under the current scheme
>>>>
>>>> lsm.enabled=selinux
>>>>
>>>> could actually mean selinux,yama,loadpin,something_else are
>>>> enabled. If we extend this behavior to when full stacking lands
>>>>
>>>> lsm.enabled=selinux,yama
>>>>
>>>> might mean selinux,yama,apparmor,loadpin,something_else
>>>>
>>>> and what that list is will vary from kernel to kernel, which I think
>>>> is harder for the user than the lsm.enabled list being what is
>>>> actually enabled at boot
>>>
>>> Ah, I think I missed this in your earlier emails. What you don't like
>>> here is that "lsm.enable=" is additive. You want it to be explicit.
>>>
>>
>> This is a path to madness.
>>
>> How about enable flags set ONLY per LSM:
>>
>> lsm.selinux.enable=x
>> lsm.apparmor.enable=x
>>
>> With no lsm.enable, and removing selinux=x and apparmor=x.
>>
>> Yes this will break existing docs, but they can be updated for newer
>> kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from
>> kernel X onwards.
>>
>> Surely distro packages and bootloaders are able to cope with changes to
>> kernel parameters?
>>
>> We can either take a one-time hit now, or build new usability debt, which
>> will confuse people forever.
> 
> I'd like to avoid this for a few reasons:
> 
> - this requires per-LSM plumbing instead of centralized plumbing
>   - each LSM needs to have its own CONFIG flag
>   - each LSM needs to have its own bootparam flag
> - SELinux has explicited stated they do not want to lose selinux=
> - this doesn't meet John's goal of having a "single explicit enable list"
> 
I can compromise on a single explicit list. My main goal is something that
is consistent and easy for the end user, and I would like to avoid
potential points of confusion if possible.

To me a list like
  lsm.enable=X,Y,Z

is best as a single explicit enable list, and it would be best to avoid
lsm.disable as it just introduces confusion.

I do think per-LSM bootparams looses the advantages of centralization,
and still requires the user to know some Kconfig info but it also gets
rid of the lsm.disable confusion.

With ordering separated out from being enabled there is a certain
cleanness to it. And perhaps most users are looking to enable/disable
a single lsm, instead of specifying exactly what security they want
on their system.

If we were to go this route I would rather drop the lsm. prefix


> I think the current proposal (in the other thread) is likely the
> sanest approach:
> 
> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE

Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
available to be enabled by default at boot.

> - Boot time enabling for selinux= and apparmor= remain
> - lsm.enable= is explicit: overrides above and omissions are disabled
wfm

> - maybe include lsm.disable= to disable anything

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 23:46                       ` John Johansen
  2018-10-02 23:46                         ` John Johansen
@ 2018-10-02 23:54                         ` Kees Cook
  2018-10-02 23:54                           ` Kees Cook
                                             ` (2 more replies)
  2018-10-03 18:17                         ` James Morris
  2 siblings, 3 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 23:54 UTC (permalink / raw)
  To: John Johansen
  Cc: James Morris, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/02/2018 04:06 PM, Kees Cook wrote:
>> I think the current proposal (in the other thread) is likely the
>> sanest approach:
>>
>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>
> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
> available to be enabled by default at boot.

That's not how I have it currently. It's a comma-separated a string,
including the reserved name "all". The default would just be
"CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
capture new LSMs by default at build-time.

>> - Boot time enabling for selinux= and apparmor= remain
>> - lsm.enable= is explicit: overrides above and omissions are disabled
> wfm

Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
would be replacing its functionality.)

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 23:54                         ` Kees Cook
@ 2018-10-02 23:54                           ` Kees Cook
  2018-10-03  0:05                           ` John Johansen
  2018-10-03 13:39                           ` Stephen Smalley
  2 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-02 23:54 UTC (permalink / raw)
  To: John Johansen
  Cc: James Morris, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/02/2018 04:06 PM, Kees Cook wrote:
>> I think the current proposal (in the other thread) is likely the
>> sanest approach:
>>
>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>
> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
> available to be enabled by default at boot.

That's not how I have it currently. It's a comma-separated a string,
including the reserved name "all". The default would just be
"CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
capture new LSMs by default at build-time.

>> - Boot time enabling for selinux= and apparmor= remain
>> - lsm.enable= is explicit: overrides above and omissions are disabled
> wfm

Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
would be replacing its functionality.)

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 23:54                         ` Kees Cook
  2018-10-02 23:54                           ` Kees Cook
@ 2018-10-03  0:05                           ` John Johansen
  2018-10-03  0:05                             ` John Johansen
  2018-10-03  0:12                             ` Kees Cook
  2018-10-03 13:39                           ` Stephen Smalley
  2 siblings, 2 replies; 184+ messages in thread
From: John Johansen @ 2018-10-03  0:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/02/2018 04:54 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>> I think the current proposal (in the other thread) is likely the
>>> sanest approach:
>>>
>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>
>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>> available to be enabled by default at boot.
> 
> That's not how I have it currently. It's a comma-separated a string,
> including the reserved name "all". The default would just be
> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
> capture new LSMs by default at build-time.
> 

I understand where you are coming from, but speaking with my distro
hat on, that is not going to work. As a distro Ubuntu very much wants
to be able to offer all the LSMs built in to the kernel so the user
can select them. But very much wants to be able to specify a default
supported subset that is enabled at boot.

I expect RH and Suse will feel similarily. Speaking for Ubuntu if this
isn't available as part of lsm stacking it will get distro patched in.

>>> - Boot time enabling for selinux= and apparmor= remain
>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>> wfm
> 
> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
> would be replacing its functionality.)
> 
> -Kees
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03  0:05                           ` John Johansen
@ 2018-10-03  0:05                             ` John Johansen
  2018-10-03  0:12                             ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-03  0:05 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/02/2018 04:54 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>> I think the current proposal (in the other thread) is likely the
>>> sanest approach:
>>>
>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>
>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>> available to be enabled by default at boot.
> 
> That's not how I have it currently. It's a comma-separated a string,
> including the reserved name "all". The default would just be
> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
> capture new LSMs by default at build-time.
> 

I understand where you are coming from, but speaking with my distro
hat on, that is not going to work. As a distro Ubuntu very much wants
to be able to offer all the LSMs built in to the kernel so the user
can select them. But very much wants to be able to specify a default
supported subset that is enabled at boot.

I expect RH and Suse will feel similarily. Speaking for Ubuntu if this
isn't available as part of lsm stacking it will get distro patched in.

>>> - Boot time enabling for selinux= and apparmor= remain
>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>> wfm
> 
> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
> would be replacing its functionality.)
> 
> -Kees
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03  0:05                           ` John Johansen
  2018-10-03  0:05                             ` John Johansen
@ 2018-10-03  0:12                             ` Kees Cook
  2018-10-03  0:12                               ` Kees Cook
  2018-10-03 13:15                               ` John Johansen
  1 sibling, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03  0:12 UTC (permalink / raw)
  To: John Johansen
  Cc: James Morris, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 5:05 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/02/2018 04:54 PM, Kees Cook wrote:
>> That's not how I have it currently. It's a comma-separated a string,
>> including the reserved name "all". The default would just be
>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>> capture new LSMs by default at build-time.
>>
>
> I understand where you are coming from, but speaking with my distro
> hat on, that is not going to work. As a distro Ubuntu very much wants
> to be able to offer all the LSMs built in to the kernel so the user
> can select them. But very much wants to be able to specify a default
> supported subset that is enabled at boot.
>
> I expect RH and Suse will feel similarily. Speaking for Ubuntu if this
> isn't available as part of lsm stacking it will get distro patched in.

Right. Ubuntu would do something like:

CONFIG_LSM_ENABLE=yama,apparmor,integrity

And that's why I wanted non-explicit lsm.enable, so that an end user
could just do:

lsm.enable=loadpin

to add loadpin.

Perhaps we could have both? "lsm.enable=+loadpin" (add loadpin to
build default list) vs "lsm.enable=loadpin" (override build default
list with ONLY loadpin).

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03  0:12                             ` Kees Cook
@ 2018-10-03  0:12                               ` Kees Cook
  2018-10-03 13:15                               ` John Johansen
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03  0:12 UTC (permalink / raw)
  To: John Johansen
  Cc: James Morris, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, Oct 2, 2018 at 5:05 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/02/2018 04:54 PM, Kees Cook wrote:
>> That's not how I have it currently. It's a comma-separated a string,
>> including the reserved name "all". The default would just be
>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>> capture new LSMs by default at build-time.
>>
>
> I understand where you are coming from, but speaking with my distro
> hat on, that is not going to work. As a distro Ubuntu very much wants
> to be able to offer all the LSMs built in to the kernel so the user
> can select them. But very much wants to be able to specify a default
> supported subset that is enabled at boot.
>
> I expect RH and Suse will feel similarily. Speaking for Ubuntu if this
> isn't available as part of lsm stacking it will get distro patched in.

Right. Ubuntu would do something like:

CONFIG_LSM_ENABLE=yama,apparmor,integrity

And that's why I wanted non-explicit lsm.enable, so that an end user
could just do:

lsm.enable=loadpin

to add loadpin.

Perhaps we could have both? "lsm.enable=+loadpin" (add loadpin to
build default list) vs "lsm.enable=loadpin" (override build default
list with ONLY loadpin).

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03  0:12                             ` Kees Cook
  2018-10-03  0:12                               ` Kees Cook
@ 2018-10-03 13:15                               ` John Johansen
  2018-10-03 13:15                                 ` John Johansen
  1 sibling, 1 reply; 184+ messages in thread
From: John Johansen @ 2018-10-03 13:15 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/02/2018 05:12 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 5:05 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/02/2018 04:54 PM, Kees Cook wrote:
>>> That's not how I have it currently. It's a comma-separated a string,
>>> including the reserved name "all". The default would just be
>>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>>> capture new LSMs by default at build-time.
>>>
>>
>> I understand where you are coming from, but speaking with my distro
>> hat on, that is not going to work. As a distro Ubuntu very much wants
>> to be able to offer all the LSMs built in to the kernel so the user
>> can select them. But very much wants to be able to specify a default
>> supported subset that is enabled at boot.
>>
>> I expect RH and Suse will feel similarily. Speaking for Ubuntu if this
>> isn't available as part of lsm stacking it will get distro patched in.
> 
> Right. Ubuntu would do something like:
> 
> CONFIG_LSM_ENABLE=yama,apparmor,integrity
> 
> And that's why I wanted non-explicit lsm.enable, so that an end user
> could just do:
> 
> lsm.enable=loadpin
> 
> to add loadpin.
> 
> Perhaps we could have both? "lsm.enable=+loadpin" (add loadpin to
> build default list) vs "lsm.enable=loadpin" (override build default
> list with ONLY loadpin).
> 

Maybe? I'm not sure what the best option is with all the competing
requirements/desires. I need to think about it more and would like
to see what others think.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 13:15                               ` John Johansen
@ 2018-10-03 13:15                                 ` John Johansen
  0 siblings, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-03 13:15 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/02/2018 05:12 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 5:05 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/02/2018 04:54 PM, Kees Cook wrote:
>>> That's not how I have it currently. It's a comma-separated a string,
>>> including the reserved name "all". The default would just be
>>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>>> capture new LSMs by default at build-time.
>>>
>>
>> I understand where you are coming from, but speaking with my distro
>> hat on, that is not going to work. As a distro Ubuntu very much wants
>> to be able to offer all the LSMs built in to the kernel so the user
>> can select them. But very much wants to be able to specify a default
>> supported subset that is enabled at boot.
>>
>> I expect RH and Suse will feel similarily. Speaking for Ubuntu if this
>> isn't available as part of lsm stacking it will get distro patched in.
> 
> Right. Ubuntu would do something like:
> 
> CONFIG_LSM_ENABLE=yama,apparmor,integrity
> 
> And that's why I wanted non-explicit lsm.enable, so that an end user
> could just do:
> 
> lsm.enable=loadpin
> 
> to add loadpin.
> 
> Perhaps we could have both? "lsm.enable=+loadpin" (add loadpin to
> build default list) vs "lsm.enable=loadpin" (override build default
> list with ONLY loadpin).
> 

Maybe? I'm not sure what the best option is with all the competing
requirements/desires. I need to think about it more and would like
to see what others think.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 23:54                         ` Kees Cook
  2018-10-02 23:54                           ` Kees Cook
  2018-10-03  0:05                           ` John Johansen
@ 2018-10-03 13:39                           ` Stephen Smalley
  2018-10-03 13:39                             ` Stephen Smalley
  2018-10-03 17:26                             ` Kees Cook
  2 siblings, 2 replies; 184+ messages in thread
From: Stephen Smalley @ 2018-10-03 13:39 UTC (permalink / raw)
  To: Kees Cook, John Johansen
  Cc: James Morris, Jordan Glover, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 07:54 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>> I think the current proposal (in the other thread) is likely the
>>> sanest approach:
>>>
>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>
>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>> available to be enabled by default at boot.
> 
> That's not how I have it currently. It's a comma-separated a string,
> including the reserved name "all". The default would just be
> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
> capture new LSMs by default at build-time.
> 
>>> - Boot time enabling for selinux= and apparmor= remain
>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>> wfm
> 
> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
> would be replacing its functionality.)

I'd like to know how distro kernel maintainers feel about it. They would 
need to understand that if they were previously setting 
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that 
behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of 
security modules (that does not include selinux, of course).  In 
practice, this means that even the distros that choose to build all 
security modules into their kernels must explicitly set 
CONFIG_LSM_ENABLE to a specific list of security modules.  So no one 
would use "all" in practice.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 13:39                           ` Stephen Smalley
@ 2018-10-03 13:39                             ` Stephen Smalley
  2018-10-03 17:26                             ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: Stephen Smalley @ 2018-10-03 13:39 UTC (permalink / raw)
  To: Kees Cook, John Johansen
  Cc: James Morris, Jordan Glover, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/02/2018 07:54 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>> I think the current proposal (in the other thread) is likely the
>>> sanest approach:
>>>
>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>
>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>> available to be enabled by default at boot.
> 
> That's not how I have it currently. It's a comma-separated a string,
> including the reserved name "all". The default would just be
> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
> capture new LSMs by default at build-time.
> 
>>> - Boot time enabling for selinux= and apparmor= remain
>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>> wfm
> 
> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
> would be replacing its functionality.)

I'd like to know how distro kernel maintainers feel about it. They would 
need to understand that if they were previously setting 
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that 
behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of 
security modules (that does not include selinux, of course).  In 
practice, this means that even the distros that choose to build all 
security modules into their kernels must explicitly set 
CONFIG_LSM_ENABLE to a specific list of security modules.  So no one 
would use "all" in practice.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 13:39                           ` Stephen Smalley
  2018-10-03 13:39                             ` Stephen Smalley
@ 2018-10-03 17:26                             ` Kees Cook
  2018-10-03 17:26                               ` Kees Cook
                                                 ` (2 more replies)
  1 sibling, 3 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 17:26 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: John Johansen, James Morris, Jordan Glover, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>>
>>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>>>
>>>> I think the current proposal (in the other thread) is likely the
>>>> sanest approach:
>>>>
>>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>>
>>>
>>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>>> available to be enabled by default at boot.
>>
>>
>> That's not how I have it currently. It's a comma-separated a string,
>> including the reserved name "all". The default would just be
>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>> capture new LSMs by default at build-time.
>>
>>>> - Boot time enabling for selinux= and apparmor= remain
>>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>>>
>>> wfm
>>
>>
>> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
>> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
>> would be replacing its functionality.)
>
>
> I'd like to know how distro kernel maintainers feel about it. They would
> need to understand that if they were previously setting
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that
> behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of
> security modules (that does not include selinux, of course).  In practice,

That's not how it would be done. See below...

> this means that even the distros that choose to build all security modules
> into their kernels must explicitly set CONFIG_LSM_ENABLE to a specific list
> of security modules.  So no one would use "all" in practice.

This is why I had originally wanted to do CONFIG_LSM_DISABLE. Right
now, distro kernel maintainers have two ways to trigger enablement:
via the SELinux and AppArmor BOOTPARAM_VALUE _and_ DEFAULT_SECURITY
(which is an implicit "enable" for Smack or TOMOYO). All the minors
are on-if-built. So, really, the BOOTPARAM_VALUEs were only used for
disabling. Distros would build what they wanted, then use
DEFAULT_SECURITY for their desired major, and if their
DEFAULT_SECURITY wasn't SELinux or AppArmor, they'd _also_ have to set
those BOOTPARAM_VALUEs to 0.

The goal of the series is to split this more cleanly between "enable"
and "order": the way to handle the LSMs is to enable _everything_ and
then set the desired init order: the first exclusive "wins". So I *do*
think the default would be CONFIG_LSM_ENALBE=all, since it's
CONFIG_LSM_ORDER= that effectively replaces CONFIG_DEFAULT_SECURITY.

Either a distro builds a very specific subset of LSMs, or they build
in all LSMs (for the user to choose from). In both cases, they set an
explicit order, which defines which exclusive LSM get selected.

AppArmor wants to drop BOOTPARAM_VALUE, which make sense, since it's
even now redundant to CONFIG_DEFAULT_SECURITY. I think it makes sense
to drop SELinux's BOOTPARAM_VALUE too. The current way to "enable" a
major LSM is via CONFIG_DEFAULT_SECURITY. No sane distro kernel is
going to set CONFIG_DEFAULT_SECURITY=selinux and
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0. If you wanted no major LSM
(but still build them all in), you'd set CONFIG_DEFAULT_SECURITY="".

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 17:26                             ` Kees Cook
@ 2018-10-03 17:26                               ` Kees Cook
  2018-10-03 19:43                               ` Stephen Smalley
  2018-10-04  5:38                               ` John Johansen
  2 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 17:26 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: John Johansen, James Morris, Jordan Glover, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>
>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>>
>>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>>>
>>>> I think the current proposal (in the other thread) is likely the
>>>> sanest approach:
>>>>
>>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>>
>>>
>>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>>> available to be enabled by default at boot.
>>
>>
>> That's not how I have it currently. It's a comma-separated a string,
>> including the reserved name "all". The default would just be
>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>> capture new LSMs by default at build-time.
>>
>>>> - Boot time enabling for selinux= and apparmor= remain
>>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>>>
>>> wfm
>>
>>
>> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
>> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
>> would be replacing its functionality.)
>
>
> I'd like to know how distro kernel maintainers feel about it. They would
> need to understand that if they were previously setting
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that
> behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of
> security modules (that does not include selinux, of course).  In practice,

That's not how it would be done. See below...

> this means that even the distros that choose to build all security modules
> into their kernels must explicitly set CONFIG_LSM_ENABLE to a specific list
> of security modules.  So no one would use "all" in practice.

This is why I had originally wanted to do CONFIG_LSM_DISABLE. Right
now, distro kernel maintainers have two ways to trigger enablement:
via the SELinux and AppArmor BOOTPARAM_VALUE _and_ DEFAULT_SECURITY
(which is an implicit "enable" for Smack or TOMOYO). All the minors
are on-if-built. So, really, the BOOTPARAM_VALUEs were only used for
disabling. Distros would build what they wanted, then use
DEFAULT_SECURITY for their desired major, and if their
DEFAULT_SECURITY wasn't SELinux or AppArmor, they'd _also_ have to set
those BOOTPARAM_VALUEs to 0.

The goal of the series is to split this more cleanly between "enable"
and "order": the way to handle the LSMs is to enable _everything_ and
then set the desired init order: the first exclusive "wins". So I *do*
think the default would be CONFIG_LSM_ENALBE=all, since it's
CONFIG_LSM_ORDER= that effectively replaces CONFIG_DEFAULT_SECURITY.

Either a distro builds a very specific subset of LSMs, or they build
in all LSMs (for the user to choose from). In both cases, they set an
explicit order, which defines which exclusive LSM get selected.

AppArmor wants to drop BOOTPARAM_VALUE, which make sense, since it's
even now redundant to CONFIG_DEFAULT_SECURITY. I think it makes sense
to drop SELinux's BOOTPARAM_VALUE too. The current way to "enable" a
major LSM is via CONFIG_DEFAULT_SECURITY. No sane distro kernel is
going to set CONFIG_DEFAULT_SECURITY=selinux and
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0. If you wanted no major LSM
(but still build them all in), you'd set CONFIG_DEFAULT_SECURITY="".

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-02 23:46                       ` John Johansen
  2018-10-02 23:46                         ` John Johansen
  2018-10-02 23:54                         ` Kees Cook
@ 2018-10-03 18:17                         ` James Morris
  2018-10-03 18:17                           ` James Morris
  2018-10-03 18:20                           ` Kees Cook
  2 siblings, 2 replies; 184+ messages in thread
From: James Morris @ 2018-10-03 18:17 UTC (permalink / raw)
  To: John Johansen
  Cc: Kees Cook, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, 2 Oct 2018, John Johansen wrote:

> To me a list like
>   lsm.enable=X,Y,Z

What about even simpler:

lsm=selinux,!apparmor,yama

> 
> is best as a single explicit enable list, and it would be best to avoid
> lsm.disable as it just introduces confusion.
> 
> I do think per-LSM bootparams looses the advantages of centralization,
> and still requires the user to know some Kconfig info but it also gets
> rid of the lsm.disable confusion.
> 
> With ordering separated out from being enabled there is a certain
> cleanness to it. And perhaps most users are looking to enable/disable
> a single lsm, instead of specifying exactly what security they want
> on their system.
> 
> If we were to go this route I would rather drop the lsm. prefix
> 
> 
> > I think the current proposal (in the other thread) is likely the
> > sanest approach:
> > 
> > - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
> > - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
> > - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
> 
> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
> available to be enabled by default at boot.
> 
> > - Boot time enabling for selinux= and apparmor= remain
> > - lsm.enable= is explicit: overrides above and omissions are disabled
> wfm
> 
> > - maybe include lsm.disable= to disable anything
> 

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 18:17                         ` James Morris
@ 2018-10-03 18:17                           ` James Morris
  2018-10-03 18:20                           ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-03 18:17 UTC (permalink / raw)
  To: John Johansen
  Cc: Kees Cook, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Tue, 2 Oct 2018, John Johansen wrote:

> To me a list like
>   lsm.enable=X,Y,Z

What about even simpler:

lsm=selinux,!apparmor,yama

> 
> is best as a single explicit enable list, and it would be best to avoid
> lsm.disable as it just introduces confusion.
> 
> I do think per-LSM bootparams looses the advantages of centralization,
> and still requires the user to know some Kconfig info but it also gets
> rid of the lsm.disable confusion.
> 
> With ordering separated out from being enabled there is a certain
> cleanness to it. And perhaps most users are looking to enable/disable
> a single lsm, instead of specifying exactly what security they want
> on their system.
> 
> If we were to go this route I would rather drop the lsm. prefix
> 
> 
> > I think the current proposal (in the other thread) is likely the
> > sanest approach:
> > 
> > - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
> > - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
> > - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
> 
> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
> available to be enabled by default at boot.
> 
> > - Boot time enabling for selinux= and apparmor= remain
> > - lsm.enable= is explicit: overrides above and omissions are disabled
> wfm
> 
> > - maybe include lsm.disable= to disable anything
> 

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 18:17                         ` James Morris
  2018-10-03 18:17                           ` James Morris
@ 2018-10-03 18:20                           ` Kees Cook
  2018-10-03 18:20                             ` Kees Cook
  2018-10-03 18:28                             ` James Morris
  1 sibling, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 18:20 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
> On Tue, 2 Oct 2018, John Johansen wrote:
>> To me a list like
>>   lsm.enable=X,Y,Z
>
> What about even simpler:
>
> lsm=selinux,!apparmor,yama

We're going to have lsm.order=, so I'd like to keep it with a dot
separator (this makes it more like module parameters, too). You want
to mix enable/disable in the same string? That implies you'd want
implicit enabling (i.e. it complements the builtin enabling), which is
opposite from what John wanted.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 18:20                           ` Kees Cook
@ 2018-10-03 18:20                             ` Kees Cook
  2018-10-03 18:28                             ` James Morris
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 18:20 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
> On Tue, 2 Oct 2018, John Johansen wrote:
>> To me a list like
>>   lsm.enable=X,Y,Z
>
> What about even simpler:
>
> lsm=selinux,!apparmor,yama

We're going to have lsm.order=, so I'd like to keep it with a dot
separator (this makes it more like module parameters, too). You want
to mix enable/disable in the same string? That implies you'd want
implicit enabling (i.e. it complements the builtin enabling), which is
opposite from what John wanted.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 18:20                           ` Kees Cook
  2018-10-03 18:20                             ` Kees Cook
@ 2018-10-03 18:28                             ` James Morris
  2018-10-03 18:28                               ` James Morris
  2018-10-03 20:10                               ` Kees Cook
  1 sibling, 2 replies; 184+ messages in thread
From: James Morris @ 2018-10-03 18:28 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, 3 Oct 2018, Kees Cook wrote:

> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
> > On Tue, 2 Oct 2018, John Johansen wrote:
> >> To me a list like
> >>   lsm.enable=X,Y,Z
> >
> > What about even simpler:
> >
> > lsm=selinux,!apparmor,yama
> 
> We're going to have lsm.order=, so I'd like to keep it with a dot
> separator (this makes it more like module parameters, too). You want
> to mix enable/disable in the same string? That implies you'd want
> implicit enabling (i.e. it complements the builtin enabling), which is
> opposite from what John wanted.
> 

Why can't this be the order as well?

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 18:28                             ` James Morris
@ 2018-10-03 18:28                               ` James Morris
  2018-10-03 20:10                               ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-03 18:28 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, 3 Oct 2018, Kees Cook wrote:

> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
> > On Tue, 2 Oct 2018, John Johansen wrote:
> >> To me a list like
> >>   lsm.enable=X,Y,Z
> >
> > What about even simpler:
> >
> > lsm=selinux,!apparmor,yama
> 
> We're going to have lsm.order=, so I'd like to keep it with a dot
> separator (this makes it more like module parameters, too). You want
> to mix enable/disable in the same string? That implies you'd want
> implicit enabling (i.e. it complements the builtin enabling), which is
> opposite from what John wanted.
> 

Why can't this be the order as well?

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 17:26                             ` Kees Cook
  2018-10-03 17:26                               ` Kees Cook
@ 2018-10-03 19:43                               ` Stephen Smalley
  2018-10-03 19:43                                 ` Stephen Smalley
  2018-10-04  5:38                               ` John Johansen
  2 siblings, 1 reply; 184+ messages in thread
From: Stephen Smalley @ 2018-10-03 19:43 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, James Morris, Jordan Glover, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/03/2018 01:26 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>>
>>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>>
>>>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>>>>
>>>>> I think the current proposal (in the other thread) is likely the
>>>>> sanest approach:
>>>>>
>>>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>>>
>>>>
>>>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>>>> available to be enabled by default at boot.
>>>
>>>
>>> That's not how I have it currently. It's a comma-separated a string,
>>> including the reserved name "all". The default would just be
>>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>>> capture new LSMs by default at build-time.
>>>
>>>>> - Boot time enabling for selinux= and apparmor= remain
>>>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>>>>
>>>> wfm
>>>
>>>
>>> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
>>> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
>>> would be replacing its functionality.)
>>
>>
>> I'd like to know how distro kernel maintainers feel about it. They would
>> need to understand that if they were previously setting
>> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that
>> behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of
>> security modules (that does not include selinux, of course).  In practice,
> 
> That's not how it would be done. See below...
> 
>> this means that even the distros that choose to build all security modules
>> into their kernels must explicitly set CONFIG_LSM_ENABLE to a specific list
>> of security modules.  So no one would use "all" in practice.
> 
> This is why I had originally wanted to do CONFIG_LSM_DISABLE. Right
> now, distro kernel maintainers have two ways to trigger enablement:
> via the SELinux and AppArmor BOOTPARAM_VALUE _and_ DEFAULT_SECURITY
> (which is an implicit "enable" for Smack or TOMOYO). All the minors
> are on-if-built. So, really, the BOOTPARAM_VALUEs were only used for
> disabling. Distros would build what they wanted, then use
> DEFAULT_SECURITY for their desired major, and if their
> DEFAULT_SECURITY wasn't SELinux or AppArmor, they'd _also_ have to set
> those BOOTPARAM_VALUEs to 0.
> 
> The goal of the series is to split this more cleanly between "enable"
> and "order": the way to handle the LSMs is to enable _everything_ and
> then set the desired init order: the first exclusive "wins". So I *do*
> think the default would be CONFIG_LSM_ENALBE=all, since it's
> CONFIG_LSM_ORDER= that effectively replaces CONFIG_DEFAULT_SECURITY.
> 
> Either a distro builds a very specific subset of LSMs, or they build
> in all LSMs (for the user to choose from). In both cases, they set an
> explicit order, which defines which exclusive LSM get selected.
> 
> AppArmor wants to drop BOOTPARAM_VALUE, which make sense, since it's
> even now redundant to CONFIG_DEFAULT_SECURITY. I think it makes sense
> to drop SELinux's BOOTPARAM_VALUE too. The current way to "enable" a
> major LSM is via CONFIG_DEFAULT_SECURITY. No sane distro kernel is
> going to set CONFIG_DEFAULT_SECURITY=selinux and
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0. If you wanted no major LSM
> (but still build them all in), you'd set CONFIG_DEFAULT_SECURITY="".

Ok, then I have no objection to removing BOOTPARAM_VALUE.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 19:43                               ` Stephen Smalley
@ 2018-10-03 19:43                                 ` Stephen Smalley
  0 siblings, 0 replies; 184+ messages in thread
From: Stephen Smalley @ 2018-10-03 19:43 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, James Morris, Jordan Glover, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/03/2018 01:26 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>>
>>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>>
>>>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>>>>
>>>>> I think the current proposal (in the other thread) is likely the
>>>>> sanest approach:
>>>>>
>>>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>>>
>>>>
>>>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>>>> available to be enabled by default at boot.
>>>
>>>
>>> That's not how I have it currently. It's a comma-separated a string,
>>> including the reserved name "all". The default would just be
>>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>>> capture new LSMs by default at build-time.
>>>
>>>>> - Boot time enabling for selinux= and apparmor= remain
>>>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>>>>
>>>> wfm
>>>
>>>
>>> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
>>> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
>>> would be replacing its functionality.)
>>
>>
>> I'd like to know how distro kernel maintainers feel about it. They would
>> need to understand that if they were previously setting
>> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that
>> behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of
>> security modules (that does not include selinux, of course).  In practice,
> 
> That's not how it would be done. See below...
> 
>> this means that even the distros that choose to build all security modules
>> into their kernels must explicitly set CONFIG_LSM_ENABLE to a specific list
>> of security modules.  So no one would use "all" in practice.
> 
> This is why I had originally wanted to do CONFIG_LSM_DISABLE. Right
> now, distro kernel maintainers have two ways to trigger enablement:
> via the SELinux and AppArmor BOOTPARAM_VALUE _and_ DEFAULT_SECURITY
> (which is an implicit "enable" for Smack or TOMOYO). All the minors
> are on-if-built. So, really, the BOOTPARAM_VALUEs were only used for
> disabling. Distros would build what they wanted, then use
> DEFAULT_SECURITY for their desired major, and if their
> DEFAULT_SECURITY wasn't SELinux or AppArmor, they'd _also_ have to set
> those BOOTPARAM_VALUEs to 0.
> 
> The goal of the series is to split this more cleanly between "enable"
> and "order": the way to handle the LSMs is to enable _everything_ and
> then set the desired init order: the first exclusive "wins". So I *do*
> think the default would be CONFIG_LSM_ENALBE=all, since it's
> CONFIG_LSM_ORDER= that effectively replaces CONFIG_DEFAULT_SECURITY.
> 
> Either a distro builds a very specific subset of LSMs, or they build
> in all LSMs (for the user to choose from). In both cases, they set an
> explicit order, which defines which exclusive LSM get selected.
> 
> AppArmor wants to drop BOOTPARAM_VALUE, which make sense, since it's
> even now redundant to CONFIG_DEFAULT_SECURITY. I think it makes sense
> to drop SELinux's BOOTPARAM_VALUE too. The current way to "enable" a
> major LSM is via CONFIG_DEFAULT_SECURITY. No sane distro kernel is
> going to set CONFIG_DEFAULT_SECURITY=selinux and
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0. If you wanted no major LSM
> (but still build them all in), you'd set CONFIG_DEFAULT_SECURITY="".

Ok, then I have no objection to removing BOOTPARAM_VALUE.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 18:28                             ` James Morris
  2018-10-03 18:28                               ` James Morris
@ 2018-10-03 20:10                               ` Kees Cook
  2018-10-03 20:10                                 ` Kees Cook
                                                   ` (2 more replies)
  1 sibling, 3 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 20:10 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>
>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>> > On Tue, 2 Oct 2018, John Johansen wrote:
>> >> To me a list like
>> >>   lsm.enable=X,Y,Z
>> >
>> > What about even simpler:
>> >
>> > lsm=selinux,!apparmor,yama
>>
>> We're going to have lsm.order=, so I'd like to keep it with a dot
>> separator (this makes it more like module parameters, too). You want
>> to mix enable/disable in the same string? That implies you'd want
>> implicit enabling (i.e. it complements the builtin enabling), which is
>> opposite from what John wanted.
>>
>
> Why can't this be the order as well?

That was covered extensively in the earlier threads. It boils down to
making sure we do not create a pattern of leaving LSMs disabled by
default when they are added to the kernel. The v1 series used
security= like this:

+       security=       [SECURITY] An ordered comma-separated list of
+                       security modules to attempt to enable at boot. If
+                       this boot parameter is not specified, only the
+                       security modules asking for initialization will be
+                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
+                       or invalid security modules will be ignored. The
+                       capability module is always loaded first, without
+                       regard to this parameter.

This meant booting "security=apparmor" would disable all the other
LSMs, which wasn't friendly at all. So "security=" was left alone (to
leave it to only select the "major" LSM: all major LSMs not matching
"security=" would be disabled). So I proposed "lsm.order=" to specify
the order things were going to be initialized in, but to avoid kernels
booting with newly added LSMs forced-off due to not being listed in
"lsm.order=", it had to have implicit fall-back for unlisted LSMs.
(i.e. anything missing from lsm.order would then follow their order in
CONFIG_LSM_ORDER, and anything missing there would fall back to
link-time ordering.) However, then the objection was raised that this
didn't provide a way to explicitly disable an LSM. So I proposed
lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
CONFIG_LSM_DISABLE.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 20:10                               ` Kees Cook
@ 2018-10-03 20:10                                 ` Kees Cook
  2018-10-03 20:36                                 ` Kees Cook
  2018-10-03 21:34                                 ` James Morris
  2 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 20:10 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>
>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>> > On Tue, 2 Oct 2018, John Johansen wrote:
>> >> To me a list like
>> >>   lsm.enable=X,Y,Z
>> >
>> > What about even simpler:
>> >
>> > lsm=selinux,!apparmor,yama
>>
>> We're going to have lsm.order=, so I'd like to keep it with a dot
>> separator (this makes it more like module parameters, too). You want
>> to mix enable/disable in the same string? That implies you'd want
>> implicit enabling (i.e. it complements the builtin enabling), which is
>> opposite from what John wanted.
>>
>
> Why can't this be the order as well?

That was covered extensively in the earlier threads. It boils down to
making sure we do not create a pattern of leaving LSMs disabled by
default when they are added to the kernel. The v1 series used
security= like this:

+       security=       [SECURITY] An ordered comma-separated list of
+                       security modules to attempt to enable at boot. If
+                       this boot parameter is not specified, only the
+                       security modules asking for initialization will be
+                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
+                       or invalid security modules will be ignored. The
+                       capability module is always loaded first, without
+                       regard to this parameter.

This meant booting "security=apparmor" would disable all the other
LSMs, which wasn't friendly at all. So "security=" was left alone (to
leave it to only select the "major" LSM: all major LSMs not matching
"security=" would be disabled). So I proposed "lsm.order=" to specify
the order things were going to be initialized in, but to avoid kernels
booting with newly added LSMs forced-off due to not being listed in
"lsm.order=", it had to have implicit fall-back for unlisted LSMs.
(i.e. anything missing from lsm.order would then follow their order in
CONFIG_LSM_ORDER, and anything missing there would fall back to
link-time ordering.) However, then the objection was raised that this
didn't provide a way to explicitly disable an LSM. So I proposed
lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
CONFIG_LSM_DISABLE.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 20:10                               ` Kees Cook
  2018-10-03 20:10                                 ` Kees Cook
@ 2018-10-03 20:36                                 ` Kees Cook
  2018-10-03 20:36                                   ` Kees Cook
                                                     ` (2 more replies)
  2018-10-03 21:34                                 ` James Morris
  2 siblings, 3 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 20:36 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>> > On Tue, 2 Oct 2018, John Johansen wrote:
>>> >> To me a list like
>>> >>   lsm.enable=X,Y,Z
>>> >
>>> > What about even simpler:
>>> >
>>> > lsm=selinux,!apparmor,yama
>>>
>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>> separator (this makes it more like module parameters, too). You want
>>> to mix enable/disable in the same string? That implies you'd want
>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>> opposite from what John wanted.
>>>
>>
>> Why can't this be the order as well?
>
> That was covered extensively in the earlier threads. It boils down to
> making sure we do not create a pattern of leaving LSMs disabled by
> default when they are added to the kernel. The v1 series used
> security= like this:
>
> +       security=       [SECURITY] An ordered comma-separated list of
> +                       security modules to attempt to enable at boot. If
> +                       this boot parameter is not specified, only the
> +                       security modules asking for initialization will be
> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
> +                       or invalid security modules will be ignored. The
> +                       capability module is always loaded first, without
> +                       regard to this parameter.
>
> This meant booting "security=apparmor" would disable all the other
> LSMs, which wasn't friendly at all. So "security=" was left alone (to
> leave it to only select the "major" LSM: all major LSMs not matching
> "security=" would be disabled). So I proposed "lsm.order=" to specify
> the order things were going to be initialized in, but to avoid kernels
> booting with newly added LSMs forced-off due to not being listed in
> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
> (i.e. anything missing from lsm.order would then follow their order in
> CONFIG_LSM_ORDER, and anything missing there would fall back to
> link-time ordering.) However, then the objection was raised that this
> didn't provide a way to explicitly disable an LSM. So I proposed
> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
> CONFIG_LSM_DISABLE.

I still think we should have all built LSMs enabled by default, with
CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER
declares their order, "lsm.order=" works as mentioned, and
"lsm.enable/disable=" make changes to what's enabled.

(This would be most like the v3 series, swapping CONFIG_LSM_ENABLE for
CONFIG_LSM_DISABLE.)

It gives us centralized ordering and centralized disabling. Distros
wanting specific LSMs are already building them, so _also_ adding them
to CONFIG_LSM_ENABLE seems redundant to me. Distros wanting all the
LSMs just want to declare the order of initialization, and maybe add
some to CONFIG_LSM_DISABLE some day, so they use CONFIG_LSM_ORDER.

I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
in, since it's just a way to disable all the other majors. I don't
like this because it will force LSMs to be disabled that don't need to
be once blob-sharing lands. The whole point of this series is to get
us away from fixed ordering and thinking about "major" vs "minor" and
towards "exclusive" or not, where we can continue to slowly chip away
at exclusivity without breaking anything.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 20:36                                 ` Kees Cook
@ 2018-10-03 20:36                                   ` Kees Cook
  2018-10-03 21:19                                   ` James Morris
  2018-10-04  5:56                                   ` John Johansen
  2 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 20:36 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>> > On Tue, 2 Oct 2018, John Johansen wrote:
>>> >> To me a list like
>>> >>   lsm.enable=X,Y,Z
>>> >
>>> > What about even simpler:
>>> >
>>> > lsm=selinux,!apparmor,yama
>>>
>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>> separator (this makes it more like module parameters, too). You want
>>> to mix enable/disable in the same string? That implies you'd want
>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>> opposite from what John wanted.
>>>
>>
>> Why can't this be the order as well?
>
> That was covered extensively in the earlier threads. It boils down to
> making sure we do not create a pattern of leaving LSMs disabled by
> default when they are added to the kernel. The v1 series used
> security= like this:
>
> +       security=       [SECURITY] An ordered comma-separated list of
> +                       security modules to attempt to enable at boot. If
> +                       this boot parameter is not specified, only the
> +                       security modules asking for initialization will be
> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
> +                       or invalid security modules will be ignored. The
> +                       capability module is always loaded first, without
> +                       regard to this parameter.
>
> This meant booting "security=apparmor" would disable all the other
> LSMs, which wasn't friendly at all. So "security=" was left alone (to
> leave it to only select the "major" LSM: all major LSMs not matching
> "security=" would be disabled). So I proposed "lsm.order=" to specify
> the order things were going to be initialized in, but to avoid kernels
> booting with newly added LSMs forced-off due to not being listed in
> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
> (i.e. anything missing from lsm.order would then follow their order in
> CONFIG_LSM_ORDER, and anything missing there would fall back to
> link-time ordering.) However, then the objection was raised that this
> didn't provide a way to explicitly disable an LSM. So I proposed
> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
> CONFIG_LSM_DISABLE.

I still think we should have all built LSMs enabled by default, with
CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER
declares their order, "lsm.order=" works as mentioned, and
"lsm.enable/disable=" make changes to what's enabled.

(This would be most like the v3 series, swapping CONFIG_LSM_ENABLE for
CONFIG_LSM_DISABLE.)

It gives us centralized ordering and centralized disabling. Distros
wanting specific LSMs are already building them, so _also_ adding them
to CONFIG_LSM_ENABLE seems redundant to me. Distros wanting all the
LSMs just want to declare the order of initialization, and maybe add
some to CONFIG_LSM_DISABLE some day, so they use CONFIG_LSM_ORDER.

I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
in, since it's just a way to disable all the other majors. I don't
like this because it will force LSMs to be disabled that don't need to
be once blob-sharing lands. The whole point of this series is to get
us away from fixed ordering and thinking about "major" vs "minor" and
towards "exclusive" or not, where we can continue to slowly chip away
at exclusivity without breaking anything.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 20:36                                 ` Kees Cook
  2018-10-03 20:36                                   ` Kees Cook
@ 2018-10-03 21:19                                   ` James Morris
  2018-10-03 21:19                                     ` James Morris
  2018-10-04  5:56                                   ` John Johansen
  2 siblings, 1 reply; 184+ messages in thread
From: James Morris @ 2018-10-03 21:19 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, 3 Oct 2018, Kees Cook wrote:

> I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
> in, since it's just a way to disable all the other majors.

Right, default doesn't make sense anymore.


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 21:19                                   ` James Morris
@ 2018-10-03 21:19                                     ` James Morris
  0 siblings, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-03 21:19 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, 3 Oct 2018, Kees Cook wrote:

> I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
> in, since it's just a way to disable all the other majors.

Right, default doesn't make sense anymore.


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 20:10                               ` Kees Cook
  2018-10-03 20:10                                 ` Kees Cook
  2018-10-03 20:36                                 ` Kees Cook
@ 2018-10-03 21:34                                 ` James Morris
  2018-10-03 21:34                                   ` James Morris
  2018-10-03 23:55                                   ` Kees Cook
  2 siblings, 2 replies; 184+ messages in thread
From: James Morris @ 2018-10-03 21:34 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, 3 Oct 2018, Kees Cook wrote:

> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
> >> > On Tue, 2 Oct 2018, John Johansen wrote:
> >> >> To me a list like
> >> >>   lsm.enable=X,Y,Z
> >> >
> >> > What about even simpler:
> >> >
> >> > lsm=selinux,!apparmor,yama
> >>
> >> We're going to have lsm.order=, so I'd like to keep it with a dot
> >> separator (this makes it more like module parameters, too). You want
> >> to mix enable/disable in the same string? That implies you'd want
> >> implicit enabling (i.e. it complements the builtin enabling), which is
> >> opposite from what John wanted.
> >>
> >
> > Why can't this be the order as well?
> 
> That was covered extensively in the earlier threads. It boils down to
> making sure we do not create a pattern of leaving LSMs disabled by
> default when they are added to the kernel. The v1 series used
> security= like this:
> 
> +       security=       [SECURITY] An ordered comma-separated list of
> +                       security modules to attempt to enable at boot. If
> +                       this boot parameter is not specified, only the
> +                       security modules asking for initialization will be
> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
> +                       or invalid security modules will be ignored. The
> +                       capability module is always loaded first, without
> +                       regard to this parameter.
> 
> This meant booting "security=apparmor" would disable all the other
> LSMs, which wasn't friendly at all. So "security=" was left alone (to
> leave it to only select the "major" LSM: all major LSMs not matching
> "security=" would be disabled). So I proposed "lsm.order=" to specify
> the order things were going to be initialized in, but to avoid kernels
> booting with newly added LSMs forced-off due to not being listed in
> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
> (i.e. anything missing from lsm.order would then follow their order in
> CONFIG_LSM_ORDER, and anything missing there would fall back to
> link-time ordering.) However, then the objection was raised that this
> didn't provide a way to explicitly disable an LSM. So I proposed
> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
> CONFIG_LSM_DISABLE.

Ok, but it may end up being clearer, simpler, and thus more secure to just 
have a single way to configure LSM.

For example:

  - All LSMs which are built are NOT enabled by default

  - You specify enablement and order via a Kconfig:

	CONFIG_LSM="selinux,yama"

  - This can be entirely overridden by a boot param:

	lsm="apparmor,landlock"

And that's it.

Of course, capabilities is always enabled and not be visible to kconfig or 
boot params.


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 21:34                                 ` James Morris
@ 2018-10-03 21:34                                   ` James Morris
  2018-10-03 23:55                                   ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-03 21:34 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, 3 Oct 2018, Kees Cook wrote:

> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
> >> > On Tue, 2 Oct 2018, John Johansen wrote:
> >> >> To me a list like
> >> >>   lsm.enable=X,Y,Z
> >> >
> >> > What about even simpler:
> >> >
> >> > lsm=selinux,!apparmor,yama
> >>
> >> We're going to have lsm.order=, so I'd like to keep it with a dot
> >> separator (this makes it more like module parameters, too). You want
> >> to mix enable/disable in the same string? That implies you'd want
> >> implicit enabling (i.e. it complements the builtin enabling), which is
> >> opposite from what John wanted.
> >>
> >
> > Why can't this be the order as well?
> 
> That was covered extensively in the earlier threads. It boils down to
> making sure we do not create a pattern of leaving LSMs disabled by
> default when they are added to the kernel. The v1 series used
> security= like this:
> 
> +       security=       [SECURITY] An ordered comma-separated list of
> +                       security modules to attempt to enable at boot. If
> +                       this boot parameter is not specified, only the
> +                       security modules asking for initialization will be
> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
> +                       or invalid security modules will be ignored. The
> +                       capability module is always loaded first, without
> +                       regard to this parameter.
> 
> This meant booting "security=apparmor" would disable all the other
> LSMs, which wasn't friendly at all. So "security=" was left alone (to
> leave it to only select the "major" LSM: all major LSMs not matching
> "security=" would be disabled). So I proposed "lsm.order=" to specify
> the order things were going to be initialized in, but to avoid kernels
> booting with newly added LSMs forced-off due to not being listed in
> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
> (i.e. anything missing from lsm.order would then follow their order in
> CONFIG_LSM_ORDER, and anything missing there would fall back to
> link-time ordering.) However, then the objection was raised that this
> didn't provide a way to explicitly disable an LSM. So I proposed
> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
> CONFIG_LSM_DISABLE.

Ok, but it may end up being clearer, simpler, and thus more secure to just 
have a single way to configure LSM.

For example:

  - All LSMs which are built are NOT enabled by default

  - You specify enablement and order via a Kconfig:

	CONFIG_LSM="selinux,yama"

  - This can be entirely overridden by a boot param:

	lsm="apparmor,landlock"

And that's it.

Of course, capabilities is always enabled and not be visible to kconfig or 
boot params.


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 21:34                                 ` James Morris
  2018-10-03 21:34                                   ` James Morris
@ 2018-10-03 23:55                                   ` Kees Cook
  2018-10-03 23:55                                     ` Kees Cook
                                                       ` (3 more replies)
  1 sibling, 4 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 23:55 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>
>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>> > On Wed, 3 Oct 2018, Kees Cook wrote:
>> >
>> >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>> >> > On Tue, 2 Oct 2018, John Johansen wrote:
>> >> >> To me a list like
>> >> >>   lsm.enable=X,Y,Z
>> >> >
>> >> > What about even simpler:
>> >> >
>> >> > lsm=selinux,!apparmor,yama
>> >>
>> >> We're going to have lsm.order=, so I'd like to keep it with a dot
>> >> separator (this makes it more like module parameters, too). You want
>> >> to mix enable/disable in the same string? That implies you'd want
>> >> implicit enabling (i.e. it complements the builtin enabling), which is
>> >> opposite from what John wanted.
>> >>
>> >
>> > Why can't this be the order as well?
>>
>> That was covered extensively in the earlier threads. It boils down to
>> making sure we do not create a pattern of leaving LSMs disabled by
>> default when they are added to the kernel. The v1 series used
>> security= like this:
>>
>> +       security=       [SECURITY] An ordered comma-separated list of
>> +                       security modules to attempt to enable at boot. If
>> +                       this boot parameter is not specified, only the
>> +                       security modules asking for initialization will be
>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>> +                       or invalid security modules will be ignored. The
>> +                       capability module is always loaded first, without
>> +                       regard to this parameter.
>>
>> This meant booting "security=apparmor" would disable all the other
>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>> leave it to only select the "major" LSM: all major LSMs not matching
>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>> the order things were going to be initialized in, but to avoid kernels
>> booting with newly added LSMs forced-off due to not being listed in
>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>> (i.e. anything missing from lsm.order would then follow their order in
>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>> link-time ordering.) However, then the objection was raised that this
>> didn't provide a way to explicitly disable an LSM. So I proposed
>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>> CONFIG_LSM_DISABLE.
>
> Ok, but it may end up being clearer, simpler, and thus more secure to just
> have a single way to configure LSM.
>
> For example:
>
>   - All LSMs which are built are NOT enabled by default
>
>   - You specify enablement and order via a Kconfig:
>
>         CONFIG_LSM="selinux,yama"
>
>   - This can be entirely overridden by a boot param:
>
>         lsm="apparmor,landlock"

This doesn't work with how SELinux and AppArmor do their bootparams,
unfortunately. (And Paul and Stephen have expressed that the
documented selinux on/off must continue to work.) For example, let's
say you've built an Ubuntu kernel with:

CONFIG_SELINUX=y
...
CONFIG_LSM="yama,apparmor"

(i.e. you want SELinux available, but not enabled, so it's left out of
CONFIG_LSM)

Then someone boots the system with:

selinux=1 security=selinux

In what order does selinux get initialized relative to yama?
(apparmor, flagged as a "legacy major", would have been disabled by
the "security=" not matching it.)


The LSM order needs to be defined externally to enablement because
something may become enabled when not listed in the order.

Now, maybe I misunderstood your earlier suggestion, and what you meant
was to do something like:

CONFIG_LSM="yama,apparmor,!selinux"

to mean "put selinux here in the order, but don't enable it". Then the
problem becomes what happens to an LSM that has been built in but not
listed in CONFIG_LSM?

Related to that, this means that when new LSMs are added, they will
need to be added to any custom CONFIG_LSM= or lsm= parameters. If
that's really how we have to go, I'll accept it, but I think it's a
bit unfriendly. :P

Another reason I don't like it is because it requires users to know
about all the LSMs to make changes. One LSM can't be added/removed
without specifying ALL of the LSMs. (i.e. there is no trivial way to
enable/disable a single LSM without it growing its own enable/disable
code as in SELinux/AppArmor. I'd hoped to make that easier for both
users and developers.) Again, I can live with it, but I think it's
unfriendly.

I just want to have a direct I can go that meets all the requirements.
:) I'm fine to ignore my sense of aesthetics if everyone can agree on
the code.

> And that's it.
>
> Of course, capabilities is always enabled and not be visible to kconfig or
> boot params.

Correct. I've made sure that's true in all the versions.

BTW, there doesn't seem to be disagreement about the earlier part of
the series, though (patches 1-10). Could these go into -next just so I
don't have to keep sending them? :)

LSM: Correctly announce start of LSM initialization
vmlinux.lds.h: Avoid copy/paste of security_init section
LSM: Rename .security_initcall section to .lsm_info
LSM: Remove initcall tracing
LSM: Convert from initcall to struct lsm_info
vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
LSM: Convert security_initcall() into DEFINE_LSM()
LSM: Record LSM name in struct lsm_info
LSM: Provide init debugging infrastructure
LSM: Don't ignore initialization failures

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 23:55                                   ` Kees Cook
@ 2018-10-03 23:55                                     ` Kees Cook
  2018-10-03 23:59                                     ` Randy Dunlap
                                                       ` (2 subsequent siblings)
  3 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-03 23:55 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>
>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>> > On Wed, 3 Oct 2018, Kees Cook wrote:
>> >
>> >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>> >> > On Tue, 2 Oct 2018, John Johansen wrote:
>> >> >> To me a list like
>> >> >>   lsm.enable=X,Y,Z
>> >> >
>> >> > What about even simpler:
>> >> >
>> >> > lsm=selinux,!apparmor,yama
>> >>
>> >> We're going to have lsm.order=, so I'd like to keep it with a dot
>> >> separator (this makes it more like module parameters, too). You want
>> >> to mix enable/disable in the same string? That implies you'd want
>> >> implicit enabling (i.e. it complements the builtin enabling), which is
>> >> opposite from what John wanted.
>> >>
>> >
>> > Why can't this be the order as well?
>>
>> That was covered extensively in the earlier threads. It boils down to
>> making sure we do not create a pattern of leaving LSMs disabled by
>> default when they are added to the kernel. The v1 series used
>> security= like this:
>>
>> +       security=       [SECURITY] An ordered comma-separated list of
>> +                       security modules to attempt to enable at boot. If
>> +                       this boot parameter is not specified, only the
>> +                       security modules asking for initialization will be
>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>> +                       or invalid security modules will be ignored. The
>> +                       capability module is always loaded first, without
>> +                       regard to this parameter.
>>
>> This meant booting "security=apparmor" would disable all the other
>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>> leave it to only select the "major" LSM: all major LSMs not matching
>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>> the order things were going to be initialized in, but to avoid kernels
>> booting with newly added LSMs forced-off due to not being listed in
>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>> (i.e. anything missing from lsm.order would then follow their order in
>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>> link-time ordering.) However, then the objection was raised that this
>> didn't provide a way to explicitly disable an LSM. So I proposed
>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>> CONFIG_LSM_DISABLE.
>
> Ok, but it may end up being clearer, simpler, and thus more secure to just
> have a single way to configure LSM.
>
> For example:
>
>   - All LSMs which are built are NOT enabled by default
>
>   - You specify enablement and order via a Kconfig:
>
>         CONFIG_LSM="selinux,yama"
>
>   - This can be entirely overridden by a boot param:
>
>         lsm="apparmor,landlock"

This doesn't work with how SELinux and AppArmor do their bootparams,
unfortunately. (And Paul and Stephen have expressed that the
documented selinux on/off must continue to work.) For example, let's
say you've built an Ubuntu kernel with:

CONFIG_SELINUX=y
...
CONFIG_LSM="yama,apparmor"

(i.e. you want SELinux available, but not enabled, so it's left out of
CONFIG_LSM)

Then someone boots the system with:

selinux=1 security=selinux

In what order does selinux get initialized relative to yama?
(apparmor, flagged as a "legacy major", would have been disabled by
the "security=" not matching it.)


The LSM order needs to be defined externally to enablement because
something may become enabled when not listed in the order.

Now, maybe I misunderstood your earlier suggestion, and what you meant
was to do something like:

CONFIG_LSM="yama,apparmor,!selinux"

to mean "put selinux here in the order, but don't enable it". Then the
problem becomes what happens to an LSM that has been built in but not
listed in CONFIG_LSM?

Related to that, this means that when new LSMs are added, they will
need to be added to any custom CONFIG_LSM= or lsm= parameters. If
that's really how we have to go, I'll accept it, but I think it's a
bit unfriendly. :P

Another reason I don't like it is because it requires users to know
about all the LSMs to make changes. One LSM can't be added/removed
without specifying ALL of the LSMs. (i.e. there is no trivial way to
enable/disable a single LSM without it growing its own enable/disable
code as in SELinux/AppArmor. I'd hoped to make that easier for both
users and developers.) Again, I can live with it, but I think it's
unfriendly.

I just want to have a direct I can go that meets all the requirements.
:) I'm fine to ignore my sense of aesthetics if everyone can agree on
the code.

> And that's it.
>
> Of course, capabilities is always enabled and not be visible to kconfig or
> boot params.

Correct. I've made sure that's true in all the versions.

BTW, there doesn't seem to be disagreement about the earlier part of
the series, though (patches 1-10). Could these go into -next just so I
don't have to keep sending them? :)

LSM: Correctly announce start of LSM initialization
vmlinux.lds.h: Avoid copy/paste of security_init section
LSM: Rename .security_initcall section to .lsm_info
LSM: Remove initcall tracing
LSM: Convert from initcall to struct lsm_info
vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
LSM: Convert security_initcall() into DEFINE_LSM()
LSM: Record LSM name in struct lsm_info
LSM: Provide init debugging infrastructure
LSM: Don't ignore initialization failures

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 23:55                                   ` Kees Cook
  2018-10-03 23:55                                     ` Kees Cook
@ 2018-10-03 23:59                                     ` Randy Dunlap
  2018-10-03 23:59                                       ` Randy Dunlap
                                                         ` (2 more replies)
  2018-10-04  6:18                                     ` John Johansen
  2018-10-04 17:49                                     ` James Morris
  3 siblings, 3 replies; 184+ messages in thread
From: Randy Dunlap @ 2018-10-03 23:59 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/3/18 4:55 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>>
>>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>>> To me a list like
>>>>>>>   lsm.enable=X,Y,Z
>>>>>>
>>>>>> What about even simpler:
>>>>>>
>>>>>> lsm=selinux,!apparmor,yama
>>>>>
>>>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>>>> separator (this makes it more like module parameters, too). You want
>>>>> to mix enable/disable in the same string? That implies you'd want
>>>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>>>> opposite from what John wanted.
>>>>>
>>>>
>>>> Why can't this be the order as well?
>>>
>>> That was covered extensively in the earlier threads. It boils down to
>>> making sure we do not create a pattern of leaving LSMs disabled by
>>> default when they are added to the kernel. The v1 series used
>>> security= like this:
>>>
>>> +       security=       [SECURITY] An ordered comma-separated list of
>>> +                       security modules to attempt to enable at boot. If
>>> +                       this boot parameter is not specified, only the
>>> +                       security modules asking for initialization will be
>>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>>> +                       or invalid security modules will be ignored. The
>>> +                       capability module is always loaded first, without
>>> +                       regard to this parameter.
>>>
>>> This meant booting "security=apparmor" would disable all the other
>>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>>> leave it to only select the "major" LSM: all major LSMs not matching
>>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>>> the order things were going to be initialized in, but to avoid kernels
>>> booting with newly added LSMs forced-off due to not being listed in
>>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>>> (i.e. anything missing from lsm.order would then follow their order in
>>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>>> link-time ordering.) However, then the objection was raised that this
>>> didn't provide a way to explicitly disable an LSM. So I proposed
>>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>>> CONFIG_LSM_DISABLE.
>>
>> Ok, but it may end up being clearer, simpler, and thus more secure to just
>> have a single way to configure LSM.
>>
>> For example:
>>
>>   - All LSMs which are built are NOT enabled by default
>>
>>   - You specify enablement and order via a Kconfig:
>>
>>         CONFIG_LSM="selinux,yama"
>>
>>   - This can be entirely overridden by a boot param:
>>
>>         lsm="apparmor,landlock"
> 
> This doesn't work with how SELinux and AppArmor do their bootparams,
> unfortunately. (And Paul and Stephen have expressed that the
> documented selinux on/off must continue to work.) For example, let's
> say you've built an Ubuntu kernel with:
> 
> CONFIG_SELINUX=y
> ...
> CONFIG_LSM="yama,apparmor"
> 
> (i.e. you want SELinux available, but not enabled, so it's left out of
> CONFIG_LSM)
> 
> Then someone boots the system with:
> 
> selinux=1 security=selinux
> 
> In what order does selinux get initialized relative to yama?
> (apparmor, flagged as a "legacy major", would have been disabled by
> the "security=" not matching it.)
> 

To me, "security=selinux" means SELinux and nothing else, so I think that
all of these params are inviting a lot of confusion.

Sorry, I don't have a good answer for this.

> 
> The LSM order needs to be defined externally to enablement because
> something may become enabled when not listed in the order.
> 
> Now, maybe I misunderstood your earlier suggestion, and what you meant
> was to do something like:
> 
> CONFIG_LSM="yama,apparmor,!selinux"
> 
> to mean "put selinux here in the order, but don't enable it". Then the
> problem becomes what happens to an LSM that has been built in but not
> listed in CONFIG_LSM?
> 
> Related to that, this means that when new LSMs are added, they will
> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
> that's really how we have to go, I'll accept it, but I think it's a
> bit unfriendly. :P
> 
> Another reason I don't like it is because it requires users to know
> about all the LSMs to make changes. One LSM can't be added/removed
> without specifying ALL of the LSMs. (i.e. there is no trivial way to
> enable/disable a single LSM without it growing its own enable/disable
> code as in SELinux/AppArmor. I'd hoped to make that easier for both
> users and developers.) Again, I can live with it, but I think it's
> unfriendly.
> 
> I just want to have a direct I can go that meets all the requirements.
> :) I'm fine to ignore my sense of aesthetics if everyone can agree on
> the code.


-- 
~Randy

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 23:59                                     ` Randy Dunlap
@ 2018-10-03 23:59                                       ` Randy Dunlap
  2018-10-04  0:03                                       ` Kees Cook
  2018-10-04  6:22                                       ` John Johansen
  2 siblings, 0 replies; 184+ messages in thread
From: Randy Dunlap @ 2018-10-03 23:59 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/3/18 4:55 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>>
>>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>>> To me a list like
>>>>>>>   lsm.enable=X,Y,Z
>>>>>>
>>>>>> What about even simpler:
>>>>>>
>>>>>> lsm=selinux,!apparmor,yama
>>>>>
>>>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>>>> separator (this makes it more like module parameters, too). You want
>>>>> to mix enable/disable in the same string? That implies you'd want
>>>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>>>> opposite from what John wanted.
>>>>>
>>>>
>>>> Why can't this be the order as well?
>>>
>>> That was covered extensively in the earlier threads. It boils down to
>>> making sure we do not create a pattern of leaving LSMs disabled by
>>> default when they are added to the kernel. The v1 series used
>>> security= like this:
>>>
>>> +       security=       [SECURITY] An ordered comma-separated list of
>>> +                       security modules to attempt to enable at boot. If
>>> +                       this boot parameter is not specified, only the
>>> +                       security modules asking for initialization will be
>>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>>> +                       or invalid security modules will be ignored. The
>>> +                       capability module is always loaded first, without
>>> +                       regard to this parameter.
>>>
>>> This meant booting "security=apparmor" would disable all the other
>>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>>> leave it to only select the "major" LSM: all major LSMs not matching
>>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>>> the order things were going to be initialized in, but to avoid kernels
>>> booting with newly added LSMs forced-off due to not being listed in
>>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>>> (i.e. anything missing from lsm.order would then follow their order in
>>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>>> link-time ordering.) However, then the objection was raised that this
>>> didn't provide a way to explicitly disable an LSM. So I proposed
>>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>>> CONFIG_LSM_DISABLE.
>>
>> Ok, but it may end up being clearer, simpler, and thus more secure to just
>> have a single way to configure LSM.
>>
>> For example:
>>
>>   - All LSMs which are built are NOT enabled by default
>>
>>   - You specify enablement and order via a Kconfig:
>>
>>         CONFIG_LSM="selinux,yama"
>>
>>   - This can be entirely overridden by a boot param:
>>
>>         lsm="apparmor,landlock"
> 
> This doesn't work with how SELinux and AppArmor do their bootparams,
> unfortunately. (And Paul and Stephen have expressed that the
> documented selinux on/off must continue to work.) For example, let's
> say you've built an Ubuntu kernel with:
> 
> CONFIG_SELINUX=y
> ...
> CONFIG_LSM="yama,apparmor"
> 
> (i.e. you want SELinux available, but not enabled, so it's left out of
> CONFIG_LSM)
> 
> Then someone boots the system with:
> 
> selinux=1 security=selinux
> 
> In what order does selinux get initialized relative to yama?
> (apparmor, flagged as a "legacy major", would have been disabled by
> the "security=" not matching it.)
> 

To me, "security=selinux" means SELinux and nothing else, so I think that
all of these params are inviting a lot of confusion.

Sorry, I don't have a good answer for this.

> 
> The LSM order needs to be defined externally to enablement because
> something may become enabled when not listed in the order.
> 
> Now, maybe I misunderstood your earlier suggestion, and what you meant
> was to do something like:
> 
> CONFIG_LSM="yama,apparmor,!selinux"
> 
> to mean "put selinux here in the order, but don't enable it". Then the
> problem becomes what happens to an LSM that has been built in but not
> listed in CONFIG_LSM?
> 
> Related to that, this means that when new LSMs are added, they will
> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
> that's really how we have to go, I'll accept it, but I think it's a
> bit unfriendly. :P
> 
> Another reason I don't like it is because it requires users to know
> about all the LSMs to make changes. One LSM can't be added/removed
> without specifying ALL of the LSMs. (i.e. there is no trivial way to
> enable/disable a single LSM without it growing its own enable/disable
> code as in SELinux/AppArmor. I'd hoped to make that easier for both
> users and developers.) Again, I can live with it, but I think it's
> unfriendly.
> 
> I just want to have a direct I can go that meets all the requirements.
> :) I'm fine to ignore my sense of aesthetics if everyone can agree on
> the code.


-- 
~Randy

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 23:59                                     ` Randy Dunlap
  2018-10-03 23:59                                       ` Randy Dunlap
@ 2018-10-04  0:03                                       ` Kees Cook
  2018-10-04  0:03                                         ` Kees Cook
  2018-10-04  6:22                                       ` John Johansen
  2 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-04  0:03 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: James Morris, John Johansen, Jordan Glover, Stephen Smalley,
	Paul Moore, Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 4:59 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> To me, "security=selinux" means SELinux and nothing else, so I think that
> all of these params are inviting a lot of confusion.
>
> Sorry, I don't have a good answer for this.

This part, at least, has a pretty clear solution. :) The consensus is
to limit "security=" to what have been considered the "major" LSMs" so
it'll work in spirit the way it was designed. The goal of the new
options, though, is to find something that'll fit all the ways LSMs
are getting used: the majors, the minors, and the coming "medium"
LSMs. The precedent is pretty good here, since "security=" already
ignores the minor LSMs: Yama and LoadPin. So it'll just control the
enable/disable of the "major" LSMs, who will carry an internal marking
indicating that they're mediated by "security=" (and no new LSMs would
get this marking).

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04  0:03                                       ` Kees Cook
@ 2018-10-04  0:03                                         ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-04  0:03 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: James Morris, John Johansen, Jordan Glover, Stephen Smalley,
	Paul Moore, Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 4:59 PM, Randy Dunlap <rdunlap@infradead.org> wrote:
> To me, "security=selinux" means SELinux and nothing else, so I think that
> all of these params are inviting a lot of confusion.
>
> Sorry, I don't have a good answer for this.

This part, at least, has a pretty clear solution. :) The consensus is
to limit "security=" to what have been considered the "major" LSMs" so
it'll work in spirit the way it was designed. The goal of the new
options, though, is to find something that'll fit all the ways LSMs
are getting used: the majors, the minors, and the coming "medium"
LSMs. The precedent is pretty good here, since "security=" already
ignores the minor LSMs: Yama and LoadPin. So it'll just control the
enable/disable of the "major" LSMs, who will carry an internal marking
indicating that they're mediated by "security=" (and no new LSMs would
get this marking).

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 17:26                             ` Kees Cook
  2018-10-03 17:26                               ` Kees Cook
  2018-10-03 19:43                               ` Stephen Smalley
@ 2018-10-04  5:38                               ` John Johansen
  2018-10-04  5:38                                 ` John Johansen
                                                   ` (2 more replies)
  2 siblings, 3 replies; 184+ messages in thread
From: John Johansen @ 2018-10-04  5:38 UTC (permalink / raw)
  To: Kees Cook, Stephen Smalley
  Cc: James Morris, Jordan Glover, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/03/2018 10:26 AM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>>
>>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>>
>>>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>>>>
>>>>> I think the current proposal (in the other thread) is likely the
>>>>> sanest approach:
>>>>>
>>>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>>>
>>>>
>>>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>>>> available to be enabled by default at boot.
>>>
>>>
>>> That's not how I have it currently. It's a comma-separated a string,
>>> including the reserved name "all". The default would just be
>>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>>> capture new LSMs by default at build-time.
>>>
>>>>> - Boot time enabling for selinux= and apparmor= remain
>>>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>>>>
>>>> wfm
>>>
>>>
>>> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
>>> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
>>> would be replacing its functionality.)
>>
>>
>> I'd like to know how distro kernel maintainers feel about it. They would
>> need to understand that if they were previously setting
>> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that
>> behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of
>> security modules (that does not include selinux, of course).  In practice,
> 
> That's not how it would be done. See below...
> 
>> this means that even the distros that choose to build all security modules
>> into their kernels must explicitly set CONFIG_LSM_ENABLE to a specific list
>> of security modules.  So no one would use "all" in practice.
> 
> This is why I had originally wanted to do CONFIG_LSM_DISABLE. Right
> now, distro kernel maintainers have two ways to trigger enablement:
> via the SELinux and AppArmor BOOTPARAM_VALUE _and_ DEFAULT_SECURITY
> (which is an implicit "enable" for Smack or TOMOYO). All the minors
> are on-if-built. So, really, the BOOTPARAM_VALUEs were only used for
> disabling. Distros would build what they wanted, then use
> DEFAULT_SECURITY for their desired major, and if their
> DEFAULT_SECURITY wasn't SELinux or AppArmor, they'd _also_ have to set
> those BOOTPARAM_VALUEs to 0.
> 
> The goal of the series is to split this more cleanly between "enable"
> and "order": the way to handle the LSMs is to enable _everything_ and
> then set the desired init order: the first exclusive "wins". So I *do*
> think the default would be CONFIG_LSM_ENALBE=all, since it's
> CONFIG_LSM_ORDER= that effectively replaces CONFIG_DEFAULT_SECURITY.
> 
but distinct of first exclusive (major) will likely be going away
once full lsm stacking land.

> Either a distro builds a very specific subset of LSMs, or they build
> in all LSMs (for the user to choose from). In both cases, they set an
> explicit order, which defines which exclusive LSM get selected.
> 
and when lsm stacking lands, that exlusive LSM goes away.

> AppArmor wants to drop BOOTPARAM_VALUE, which make sense, since it's
> even now redundant to CONFIG_DEFAULT_SECURITY. I think it makes sense
> to drop SELinux's BOOTPARAM_VALUE too. The current way to "enable" a
> major LSM is via CONFIG_DEFAULT_SECURITY. No sane distro kernel is
> going to set CONFIG_DEFAULT_SECURITY=selinux and
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0. If you wanted no major LSM
> (but still build them all in), you'd set CONFIG_DEFAULT_SECURITY="".
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04  5:38                               ` John Johansen
@ 2018-10-04  5:38                                 ` John Johansen
  2018-10-04 16:02                                 ` Kees Cook
  2018-10-08 14:25                                 ` Paul Moore
  2 siblings, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-04  5:38 UTC (permalink / raw)
  To: Kees Cook, Stephen Smalley
  Cc: James Morris, Jordan Glover, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/03/2018 10:26 AM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On 10/02/2018 07:54 PM, Kees Cook wrote:
>>>
>>> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>>
>>>> On 10/02/2018 04:06 PM, Kees Cook wrote:
>>>>>
>>>>> I think the current proposal (in the other thread) is likely the
>>>>> sanest approach:
>>>>>
>>>>> - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE
>>>>> - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE
>>>>> - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE
>>>>
>>>>
>>>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM
>>>> available to be enabled by default at boot.
>>>
>>>
>>> That's not how I have it currently. It's a comma-separated a string,
>>> including the reserved name "all". The default would just be
>>> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to
>>> capture new LSMs by default at build-time.
>>>
>>>>> - Boot time enabling for selinux= and apparmor= remain
>>>>> - lsm.enable= is explicit: overrides above and omissions are disabled
>>>>
>>>> wfm
>>>
>>>
>>> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel
>>> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE
>>> would be replacing its functionality.)
>>
>>
>> I'd like to know how distro kernel maintainers feel about it. They would
>> need to understand that if they were previously setting
>> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that
>> behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of
>> security modules (that does not include selinux, of course).  In practice,
> 
> That's not how it would be done. See below...
> 
>> this means that even the distros that choose to build all security modules
>> into their kernels must explicitly set CONFIG_LSM_ENABLE to a specific list
>> of security modules.  So no one would use "all" in practice.
> 
> This is why I had originally wanted to do CONFIG_LSM_DISABLE. Right
> now, distro kernel maintainers have two ways to trigger enablement:
> via the SELinux and AppArmor BOOTPARAM_VALUE _and_ DEFAULT_SECURITY
> (which is an implicit "enable" for Smack or TOMOYO). All the minors
> are on-if-built. So, really, the BOOTPARAM_VALUEs were only used for
> disabling. Distros would build what they wanted, then use
> DEFAULT_SECURITY for their desired major, and if their
> DEFAULT_SECURITY wasn't SELinux or AppArmor, they'd _also_ have to set
> those BOOTPARAM_VALUEs to 0.
> 
> The goal of the series is to split this more cleanly between "enable"
> and "order": the way to handle the LSMs is to enable _everything_ and
> then set the desired init order: the first exclusive "wins". So I *do*
> think the default would be CONFIG_LSM_ENALBE=all, since it's
> CONFIG_LSM_ORDER= that effectively replaces CONFIG_DEFAULT_SECURITY.
> 
but distinct of first exclusive (major) will likely be going away
once full lsm stacking land.

> Either a distro builds a very specific subset of LSMs, or they build
> in all LSMs (for the user to choose from). In both cases, they set an
> explicit order, which defines which exclusive LSM get selected.
> 
and when lsm stacking lands, that exlusive LSM goes away.

> AppArmor wants to drop BOOTPARAM_VALUE, which make sense, since it's
> even now redundant to CONFIG_DEFAULT_SECURITY. I think it makes sense
> to drop SELinux's BOOTPARAM_VALUE too. The current way to "enable" a
> major LSM is via CONFIG_DEFAULT_SECURITY. No sane distro kernel is
> going to set CONFIG_DEFAULT_SECURITY=selinux and
> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0. If you wanted no major LSM
> (but still build them all in), you'd set CONFIG_DEFAULT_SECURITY="".
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 20:36                                 ` Kees Cook
  2018-10-03 20:36                                   ` Kees Cook
  2018-10-03 21:19                                   ` James Morris
@ 2018-10-04  5:56                                   ` John Johansen
  2018-10-04  5:56                                     ` John Johansen
  2018-10-04 16:18                                     ` Kees Cook
  2 siblings, 2 replies; 184+ messages in thread
From: John Johansen @ 2018-10-04  5:56 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/03/2018 01:36 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>
>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>> To me a list like
>>>>>>   lsm.enable=X,Y,Z
>>>>>
>>>>> What about even simpler:
>>>>>
>>>>> lsm=selinux,!apparmor,yama
>>>>
>>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>>> separator (this makes it more like module parameters, too). You want
>>>> to mix enable/disable in the same string? That implies you'd want
>>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>>> opposite from what John wanted.
>>>>
>>>
>>> Why can't this be the order as well?
>>
>> That was covered extensively in the earlier threads. It boils down to
>> making sure we do not create a pattern of leaving LSMs disabled by
>> default when they are added to the kernel. The v1 series used
>> security= like this:
>>
>> +       security=       [SECURITY] An ordered comma-separated list of
>> +                       security modules to attempt to enable at boot. If
>> +                       this boot parameter is not specified, only the
>> +                       security modules asking for initialization will be
>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>> +                       or invalid security modules will be ignored. The
>> +                       capability module is always loaded first, without
>> +                       regard to this parameter.
>>
>> This meant booting "security=apparmor" would disable all the other
>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>> leave it to only select the "major" LSM: all major LSMs not matching
>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>> the order things were going to be initialized in, but to avoid kernels
>> booting with newly added LSMs forced-off due to not being listed in
>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>> (i.e. anything missing from lsm.order would then follow their order in
>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>> link-time ordering.) However, then the objection was raised that this
>> didn't provide a way to explicitly disable an LSM. So I proposed
>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>> CONFIG_LSM_DISABLE.
> 
> I still think we should have all built LSMs enabled by default, with
> CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER

and this as a distro ubuntu does not want.
Ubuntu wants to make yes available by building them in, but does NOT
want all the LSM enabled by default, not even necessarily all minor LSMs.

As a distro we want a supported set as default, and users can opt-in
to new LSMs. If a new LSM comes along we don't want it enabled by
default, which happens Using the lsm disable approach.

> declares their order, "lsm.order=" works as mentioned, and
> "lsm.enable/disable=" make changes to what's enabled.
> 
> (This would be most like the v3 series, swapping CONFIG_LSM_ENABLE for
> CONFIG_LSM_DISABLE.)
> 
> It gives us centralized ordering and centralized disabling. Distros
> wanting specific LSMs are already building them, so _also_ adding them
> to CONFIG_LSM_ENABLE seems redundant to me. Distros wanting all the

except as a disto we want to build in all LSMs by default but NOT have
new LSMs enabled by default.

The disable approach either mean we don't offer new LSMs in the
supported kernels, OR me distro patch so we have the enabled by
default list.

> LSMs just want to declare the order of initialization, and maybe add
> some to CONFIG_LSM_DISABLE some day, so they use CONFIG_LSM_ORDER.
> 
individual LSMs may want that.

> I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
> in, since it's just a way to disable all the other majors. I don't
> like this because it will force LSMs to be disabled that don't need to
> be once blob-sharing lands. The whole point of this series is to get
> us away from fixed ordering and thinking about "major" vs "minor" and
> towards "exclusive" or not, where we can continue to slowly chip away
> at exclusivity without breaking anything.
> 
sure we definitely want to get away form "major" vs "minor" and in
generally even exclusive, except where to LSMs just can't live
with each other.

But that doesn't mean dropping something like default security. The
mistake with the current DEFAULT_SECURITY was that it only applied
to major LSMs, not the minor ones.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04  5:56                                   ` John Johansen
@ 2018-10-04  5:56                                     ` John Johansen
  2018-10-04 16:18                                     ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-04  5:56 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/03/2018 01:36 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 1:10 PM, Kees Cook <keescook@chromium.org> wrote:
>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>
>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>> To me a list like
>>>>>>   lsm.enable=X,Y,Z
>>>>>
>>>>> What about even simpler:
>>>>>
>>>>> lsm=selinux,!apparmor,yama
>>>>
>>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>>> separator (this makes it more like module parameters, too). You want
>>>> to mix enable/disable in the same string? That implies you'd want
>>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>>> opposite from what John wanted.
>>>>
>>>
>>> Why can't this be the order as well?
>>
>> That was covered extensively in the earlier threads. It boils down to
>> making sure we do not create a pattern of leaving LSMs disabled by
>> default when they are added to the kernel. The v1 series used
>> security= like this:
>>
>> +       security=       [SECURITY] An ordered comma-separated list of
>> +                       security modules to attempt to enable at boot. If
>> +                       this boot parameter is not specified, only the
>> +                       security modules asking for initialization will be
>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>> +                       or invalid security modules will be ignored. The
>> +                       capability module is always loaded first, without
>> +                       regard to this parameter.
>>
>> This meant booting "security=apparmor" would disable all the other
>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>> leave it to only select the "major" LSM: all major LSMs not matching
>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>> the order things were going to be initialized in, but to avoid kernels
>> booting with newly added LSMs forced-off due to not being listed in
>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>> (i.e. anything missing from lsm.order would then follow their order in
>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>> link-time ordering.) However, then the objection was raised that this
>> didn't provide a way to explicitly disable an LSM. So I proposed
>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>> CONFIG_LSM_DISABLE.
> 
> I still think we should have all built LSMs enabled by default, with
> CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER

and this as a distro ubuntu does not want.
Ubuntu wants to make yes available by building them in, but does NOT
want all the LSM enabled by default, not even necessarily all minor LSMs.

As a distro we want a supported set as default, and users can opt-in
to new LSMs. If a new LSM comes along we don't want it enabled by
default, which happens Using the lsm disable approach.

> declares their order, "lsm.order=" works as mentioned, and
> "lsm.enable/disable=" make changes to what's enabled.
> 
> (This would be most like the v3 series, swapping CONFIG_LSM_ENABLE for
> CONFIG_LSM_DISABLE.)
> 
> It gives us centralized ordering and centralized disabling. Distros
> wanting specific LSMs are already building them, so _also_ adding them
> to CONFIG_LSM_ENABLE seems redundant to me. Distros wanting all the

except as a disto we want to build in all LSMs by default but NOT have
new LSMs enabled by default.

The disable approach either mean we don't offer new LSMs in the
supported kernels, OR me distro patch so we have the enabled by
default list.

> LSMs just want to declare the order of initialization, and maybe add
> some to CONFIG_LSM_DISABLE some day, so they use CONFIG_LSM_ORDER.
> 
individual LSMs may want that.

> I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
> in, since it's just a way to disable all the other majors. I don't
> like this because it will force LSMs to be disabled that don't need to
> be once blob-sharing lands. The whole point of this series is to get
> us away from fixed ordering and thinking about "major" vs "minor" and
> towards "exclusive" or not, where we can continue to slowly chip away
> at exclusivity without breaking anything.
> 
sure we definitely want to get away form "major" vs "minor" and in
generally even exclusive, except where to LSMs just can't live
with each other.

But that doesn't mean dropping something like default security. The
mistake with the current DEFAULT_SECURITY was that it only applied
to major LSMs, not the minor ones.

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 23:55                                   ` Kees Cook
  2018-10-03 23:55                                     ` Kees Cook
  2018-10-03 23:59                                     ` Randy Dunlap
@ 2018-10-04  6:18                                     ` John Johansen
  2018-10-04  6:18                                       ` John Johansen
  2018-10-04 17:49                                     ` James Morris
  3 siblings, 1 reply; 184+ messages in thread
From: John Johansen @ 2018-10-04  6:18 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/03/2018 04:55 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>>
>>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>>> To me a list like
>>>>>>>   lsm.enable=X,Y,Z
>>>>>>
>>>>>> What about even simpler:
>>>>>>
>>>>>> lsm=selinux,!apparmor,yama
>>>>>
>>>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>>>> separator (this makes it more like module parameters, too). You want
>>>>> to mix enable/disable in the same string? That implies you'd want
>>>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>>>> opposite from what John wanted.
>>>>>
>>>>
>>>> Why can't this be the order as well?
>>>
>>> That was covered extensively in the earlier threads. It boils down to
>>> making sure we do not create a pattern of leaving LSMs disabled by
>>> default when they are added to the kernel. The v1 series used
>>> security= like this:
>>>
>>> +       security=       [SECURITY] An ordered comma-separated list of
>>> +                       security modules to attempt to enable at boot. If
>>> +                       this boot parameter is not specified, only the
>>> +                       security modules asking for initialization will be
>>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>>> +                       or invalid security modules will be ignored. The
>>> +                       capability module is always loaded first, without
>>> +                       regard to this parameter.
>>>
>>> This meant booting "security=apparmor" would disable all the other
>>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>>> leave it to only select the "major" LSM: all major LSMs not matching
>>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>>> the order things were going to be initialized in, but to avoid kernels
>>> booting with newly added LSMs forced-off due to not being listed in
>>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>>> (i.e. anything missing from lsm.order would then follow their order in
>>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>>> link-time ordering.) However, then the objection was raised that this
>>> didn't provide a way to explicitly disable an LSM. So I proposed
>>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>>> CONFIG_LSM_DISABLE.
>>
>> Ok, but it may end up being clearer, simpler, and thus more secure to just
>> have a single way to configure LSM.
>>
>> For example:
>>
>>   - All LSMs which are built are NOT enabled by default
>>
>>   - You specify enablement and order via a Kconfig:
>>
>>         CONFIG_LSM="selinux,yama"
>>
>>   - This can be entirely overridden by a boot param:
>>
>>         lsm="apparmor,landlock"
> 
> This doesn't work with how SELinux and AppArmor do their bootparams,
> unfortunately. (And Paul and Stephen have expressed that the
> documented selinux on/off must continue to work.) For example, let's
> say you've built an Ubuntu kernel with:
> 
> CONFIG_SELINUX=y
> ...
> CONFIG_LSM="yama,apparmor"
> 
> (i.e. you want SELinux available, but not enabled, so it's left out of
> CONFIG_LSM)
> 
> Then someone boots the system with:
> 
> selinux=1 security=selinux
> 
> In what order does selinux get initialized relative to yama?
> (apparmor, flagged as a "legacy major", would have been disabled by
> the "security=" not matching it.)
> 
> 
> The LSM order needs to be defined externally to enablement because
> something may become enabled when not listed in the order.
> 
it doesn't have to be that way. The only argument I can see for
ordering being separate from enablement are
- the order doesn't matter to some LSMs but other LSMs (like landlock)
  need to be in a specific order.

  Separating the ordering from enablement  means the user doesn't
  have to take this into account when overriding a default enablement.

> Now, maybe I misunderstood your earlier suggestion, and what you meant
> was to do something like:
> 
> CONFIG_LSM="yama,apparmor,!selinux"
> 
> to mean "put selinux here in the order, but don't enable it". Then the
> problem becomes what happens to an LSM that has been built in but not
> listed in CONFIG_LSM?
> 
it should be disabled. I know that is not what we have today but
does current behavior of splitting how minor and major LSM enablement
is done was a mistake

> Related to that, this means that when new LSMs are added, they will
> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
> that's really how we have to go, I'll accept it, but I think it's a
> bit unfriendly. :P
> 
That is exactly was will happen in at least some distros. Distros
are committed to maintaining a certain configuration. If some new
LSM comes along it shouldn't change the support config until the
distro can evaluate any interaction will the current supported
configuration.

As a concrete example, the Ubuntu hwe kernels (newer kernels on
LTS releases, are going to want to specify the hwe kernel config
is the same as the release kernel except for few well vetted
exceptions. 

> Another reason I don't like it is because it requires users to know
> about all the LSMs to make changes. One LSM can't be added/removed

The don't have to know about all LSMs, but they do need to know
what the distro has as default set.

> without specifying ALL of the LSMs. (i.e. there is no trivial way to
> enable/disable a single LSM without it growing its own enable/disable
> code as in SELinux/AppArmor. I'd hoped to make that easier for both
> users and developers.) Again, I can live with it, but I think it's
> unfriendly.
> 

well unfriendly to who, and define users :)
- its probably unfriendly to the developer wanting to work with
  a specific LSM.
- a user messing with the different LSMs, yeah probably
- a regular user, generally shouldn't have to know.
- a distro trying to support a specific configuration, very much
  wants to define what is enabled/supported. Whether through
  individual LSM logic, or a centralized place

> I just want to have a direct I can go that meets all the requirements.
> :) I'm fine to ignore my sense of aesthetics if everyone can agree on
> the code.
> 
>> And that's it.
>>
>> Of course, capabilities is always enabled and not be visible to kconfig or
>> boot params.
> 
> Correct. I've made sure that's true in all the versions.
> 
> BTW, there doesn't seem to be disagreement about the earlier part of
> the series, though (patches 1-10). Could these go into -next just so I
> don't have to keep sending them? :)
> 
> LSM: Correctly announce start of LSM initialization
> vmlinux.lds.h: Avoid copy/paste of security_init section
> LSM: Rename .security_initcall section to .lsm_info
> LSM: Remove initcall tracing
> LSM: Convert from initcall to struct lsm_info
> vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
> LSM: Convert security_initcall() into DEFINE_LSM()
> LSM: Record LSM name in struct lsm_info
> LSM: Provide init debugging infrastructure
> LSM: Don't ignore initialization failures
> 
> Thanks!
> 
> -Kees
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04  6:18                                     ` John Johansen
@ 2018-10-04  6:18                                       ` John Johansen
  0 siblings, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-04  6:18 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/03/2018 04:55 PM, Kees Cook wrote:
> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>
>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>>
>>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>>> To me a list like
>>>>>>>   lsm.enable=X,Y,Z
>>>>>>
>>>>>> What about even simpler:
>>>>>>
>>>>>> lsm=selinux,!apparmor,yama
>>>>>
>>>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>>>> separator (this makes it more like module parameters, too). You want
>>>>> to mix enable/disable in the same string? That implies you'd want
>>>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>>>> opposite from what John wanted.
>>>>>
>>>>
>>>> Why can't this be the order as well?
>>>
>>> That was covered extensively in the earlier threads. It boils down to
>>> making sure we do not create a pattern of leaving LSMs disabled by
>>> default when they are added to the kernel. The v1 series used
>>> security= like this:
>>>
>>> +       security=       [SECURITY] An ordered comma-separated list of
>>> +                       security modules to attempt to enable at boot. If
>>> +                       this boot parameter is not specified, only the
>>> +                       security modules asking for initialization will be
>>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>>> +                       or invalid security modules will be ignored. The
>>> +                       capability module is always loaded first, without
>>> +                       regard to this parameter.
>>>
>>> This meant booting "security=apparmor" would disable all the other
>>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>>> leave it to only select the "major" LSM: all major LSMs not matching
>>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>>> the order things were going to be initialized in, but to avoid kernels
>>> booting with newly added LSMs forced-off due to not being listed in
>>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>>> (i.e. anything missing from lsm.order would then follow their order in
>>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>>> link-time ordering.) However, then the objection was raised that this
>>> didn't provide a way to explicitly disable an LSM. So I proposed
>>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>>> CONFIG_LSM_DISABLE.
>>
>> Ok, but it may end up being clearer, simpler, and thus more secure to just
>> have a single way to configure LSM.
>>
>> For example:
>>
>>   - All LSMs which are built are NOT enabled by default
>>
>>   - You specify enablement and order via a Kconfig:
>>
>>         CONFIG_LSM="selinux,yama"
>>
>>   - This can be entirely overridden by a boot param:
>>
>>         lsm="apparmor,landlock"
> 
> This doesn't work with how SELinux and AppArmor do their bootparams,
> unfortunately. (And Paul and Stephen have expressed that the
> documented selinux on/off must continue to work.) For example, let's
> say you've built an Ubuntu kernel with:
> 
> CONFIG_SELINUX=y
> ...
> CONFIG_LSM="yama,apparmor"
> 
> (i.e. you want SELinux available, but not enabled, so it's left out of
> CONFIG_LSM)
> 
> Then someone boots the system with:
> 
> selinux=1 security=selinux
> 
> In what order does selinux get initialized relative to yama?
> (apparmor, flagged as a "legacy major", would have been disabled by
> the "security=" not matching it.)
> 
> 
> The LSM order needs to be defined externally to enablement because
> something may become enabled when not listed in the order.
> 
it doesn't have to be that way. The only argument I can see for
ordering being separate from enablement are
- the order doesn't matter to some LSMs but other LSMs (like landlock)
  need to be in a specific order.

  Separating the ordering from enablement  means the user doesn't
  have to take this into account when overriding a default enablement.

> Now, maybe I misunderstood your earlier suggestion, and what you meant
> was to do something like:
> 
> CONFIG_LSM="yama,apparmor,!selinux"
> 
> to mean "put selinux here in the order, but don't enable it". Then the
> problem becomes what happens to an LSM that has been built in but not
> listed in CONFIG_LSM?
> 
it should be disabled. I know that is not what we have today but
does current behavior of splitting how minor and major LSM enablement
is done was a mistake

> Related to that, this means that when new LSMs are added, they will
> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
> that's really how we have to go, I'll accept it, but I think it's a
> bit unfriendly. :P
> 
That is exactly was will happen in at least some distros. Distros
are committed to maintaining a certain configuration. If some new
LSM comes along it shouldn't change the support config until the
distro can evaluate any interaction will the current supported
configuration.

As a concrete example, the Ubuntu hwe kernels (newer kernels on
LTS releases, are going to want to specify the hwe kernel config
is the same as the release kernel except for few well vetted
exceptions. 

> Another reason I don't like it is because it requires users to know
> about all the LSMs to make changes. One LSM can't be added/removed

The don't have to know about all LSMs, but they do need to know
what the distro has as default set.

> without specifying ALL of the LSMs. (i.e. there is no trivial way to
> enable/disable a single LSM without it growing its own enable/disable
> code as in SELinux/AppArmor. I'd hoped to make that easier for both
> users and developers.) Again, I can live with it, but I think it's
> unfriendly.
> 

well unfriendly to who, and define users :)
- its probably unfriendly to the developer wanting to work with
  a specific LSM.
- a user messing with the different LSMs, yeah probably
- a regular user, generally shouldn't have to know.
- a distro trying to support a specific configuration, very much
  wants to define what is enabled/supported. Whether through
  individual LSM logic, or a centralized place

> I just want to have a direct I can go that meets all the requirements.
> :) I'm fine to ignore my sense of aesthetics if everyone can agree on
> the code.
> 
>> And that's it.
>>
>> Of course, capabilities is always enabled and not be visible to kconfig or
>> boot params.
> 
> Correct. I've made sure that's true in all the versions.
> 
> BTW, there doesn't seem to be disagreement about the earlier part of
> the series, though (patches 1-10). Could these go into -next just so I
> don't have to keep sending them? :)
> 
> LSM: Correctly announce start of LSM initialization
> vmlinux.lds.h: Avoid copy/paste of security_init section
> LSM: Rename .security_initcall section to .lsm_info
> LSM: Remove initcall tracing
> LSM: Convert from initcall to struct lsm_info
> vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
> LSM: Convert security_initcall() into DEFINE_LSM()
> LSM: Record LSM name in struct lsm_info
> LSM: Provide init debugging infrastructure
> LSM: Don't ignore initialization failures
> 
> Thanks!
> 
> -Kees
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 23:59                                     ` Randy Dunlap
  2018-10-03 23:59                                       ` Randy Dunlap
  2018-10-04  0:03                                       ` Kees Cook
@ 2018-10-04  6:22                                       ` John Johansen
  2018-10-04  6:22                                         ` John Johansen
  2 siblings, 1 reply; 184+ messages in thread
From: John Johansen @ 2018-10-04  6:22 UTC (permalink / raw)
  To: Randy Dunlap, Kees Cook, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/03/2018 04:59 PM, Randy Dunlap wrote:
> On 10/3/18 4:55 PM, Kees Cook wrote:
>> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>
>>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>>>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>>>
>>>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>>>> To me a list like
>>>>>>>>   lsm.enable=X,Y,Z
>>>>>>>
>>>>>>> What about even simpler:
>>>>>>>
>>>>>>> lsm=selinux,!apparmor,yama
>>>>>>
>>>>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>>>>> separator (this makes it more like module parameters, too). You want
>>>>>> to mix enable/disable in the same string? That implies you'd want
>>>>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>>>>> opposite from what John wanted.
>>>>>>
>>>>>
>>>>> Why can't this be the order as well?
>>>>
>>>> That was covered extensively in the earlier threads. It boils down to
>>>> making sure we do not create a pattern of leaving LSMs disabled by
>>>> default when they are added to the kernel. The v1 series used
>>>> security= like this:
>>>>
>>>> +       security=       [SECURITY] An ordered comma-separated list of
>>>> +                       security modules to attempt to enable at boot. If
>>>> +                       this boot parameter is not specified, only the
>>>> +                       security modules asking for initialization will be
>>>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>>>> +                       or invalid security modules will be ignored. The
>>>> +                       capability module is always loaded first, without
>>>> +                       regard to this parameter.
>>>>
>>>> This meant booting "security=apparmor" would disable all the other
>>>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>>>> leave it to only select the "major" LSM: all major LSMs not matching
>>>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>>>> the order things were going to be initialized in, but to avoid kernels
>>>> booting with newly added LSMs forced-off due to not being listed in
>>>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>>>> (i.e. anything missing from lsm.order would then follow their order in
>>>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>>>> link-time ordering.) However, then the objection was raised that this
>>>> didn't provide a way to explicitly disable an LSM. So I proposed
>>>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>>>> CONFIG_LSM_DISABLE.
>>>
>>> Ok, but it may end up being clearer, simpler, and thus more secure to just
>>> have a single way to configure LSM.
>>>
>>> For example:
>>>
>>>   - All LSMs which are built are NOT enabled by default
>>>
>>>   - You specify enablement and order via a Kconfig:
>>>
>>>         CONFIG_LSM="selinux,yama"
>>>
>>>   - This can be entirely overridden by a boot param:
>>>
>>>         lsm="apparmor,landlock"
>>
>> This doesn't work with how SELinux and AppArmor do their bootparams,
>> unfortunately. (And Paul and Stephen have expressed that the
>> documented selinux on/off must continue to work.) For example, let's
>> say you've built an Ubuntu kernel with:
>>
>> CONFIG_SELINUX=y
>> ...
>> CONFIG_LSM="yama,apparmor"
>>
>> (i.e. you want SELinux available, but not enabled, so it's left out of
>> CONFIG_LSM)
>>
>> Then someone boots the system with:
>>
>> selinux=1 security=selinux
>>
>> In what order does selinux get initialized relative to yama?
>> (apparmor, flagged as a "legacy major", would have been disabled by
>> the "security=" not matching it.)
>>
> 
> To me, "security=selinux" means SELinux and nothing else, so I think that
> all of these params are inviting a lot of confusion.
> 
> Sorry, I don't have a good answer for this.
> 

Your not the only one. I have had users ask about why they are getting
other security messures (yama in particular) when they specified a
specific security=



>>
>> The LSM order needs to be defined externally to enablement because
>> something may become enabled when not listed in the order.
>>
>> Now, maybe I misunderstood your earlier suggestion, and what you meant
>> was to do something like:
>>
>> CONFIG_LSM="yama,apparmor,!selinux"
>>
>> to mean "put selinux here in the order, but don't enable it". Then the
>> problem becomes what happens to an LSM that has been built in but not
>> listed in CONFIG_LSM?
>>
>> Related to that, this means that when new LSMs are added, they will
>> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
>> that's really how we have to go, I'll accept it, but I think it's a
>> bit unfriendly. :P
>>
>> Another reason I don't like it is because it requires users to know
>> about all the LSMs to make changes. One LSM can't be added/removed
>> without specifying ALL of the LSMs. (i.e. there is no trivial way to
>> enable/disable a single LSM without it growing its own enable/disable
>> code as in SELinux/AppArmor. I'd hoped to make that easier for both
>> users and developers.) Again, I can live with it, but I think it's
>> unfriendly.
>>
>> I just want to have a direct I can go that meets all the requirements.
>> :) I'm fine to ignore my sense of aesthetics if everyone can agree on
>> the code.
> 
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04  6:22                                       ` John Johansen
@ 2018-10-04  6:22                                         ` John Johansen
  0 siblings, 0 replies; 184+ messages in thread
From: John Johansen @ 2018-10-04  6:22 UTC (permalink / raw)
  To: Randy Dunlap, Kees Cook, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 10/03/2018 04:59 PM, Randy Dunlap wrote:
> On 10/3/18 4:55 PM, Kees Cook wrote:
>> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>
>>>> On Wed, Oct 3, 2018 at 11:28 AM, James Morris <jmorris@namei.org> wrote:
>>>>> On Wed, 3 Oct 2018, Kees Cook wrote:
>>>>>
>>>>>> On Wed, Oct 3, 2018 at 11:17 AM, James Morris <jmorris@namei.org> wrote:
>>>>>>> On Tue, 2 Oct 2018, John Johansen wrote:
>>>>>>>> To me a list like
>>>>>>>>   lsm.enable=X,Y,Z
>>>>>>>
>>>>>>> What about even simpler:
>>>>>>>
>>>>>>> lsm=selinux,!apparmor,yama
>>>>>>
>>>>>> We're going to have lsm.order=, so I'd like to keep it with a dot
>>>>>> separator (this makes it more like module parameters, too). You want
>>>>>> to mix enable/disable in the same string? That implies you'd want
>>>>>> implicit enabling (i.e. it complements the builtin enabling), which is
>>>>>> opposite from what John wanted.
>>>>>>
>>>>>
>>>>> Why can't this be the order as well?
>>>>
>>>> That was covered extensively in the earlier threads. It boils down to
>>>> making sure we do not create a pattern of leaving LSMs disabled by
>>>> default when they are added to the kernel. The v1 series used
>>>> security= like this:
>>>>
>>>> +       security=       [SECURITY] An ordered comma-separated list of
>>>> +                       security modules to attempt to enable at boot. If
>>>> +                       this boot parameter is not specified, only the
>>>> +                       security modules asking for initialization will be
>>>> +                       enabled (see CONFIG_DEFAULT_SECURITY). Duplicate
>>>> +                       or invalid security modules will be ignored. The
>>>> +                       capability module is always loaded first, without
>>>> +                       regard to this parameter.
>>>>
>>>> This meant booting "security=apparmor" would disable all the other
>>>> LSMs, which wasn't friendly at all. So "security=" was left alone (to
>>>> leave it to only select the "major" LSM: all major LSMs not matching
>>>> "security=" would be disabled). So I proposed "lsm.order=" to specify
>>>> the order things were going to be initialized in, but to avoid kernels
>>>> booting with newly added LSMs forced-off due to not being listed in
>>>> "lsm.order=", it had to have implicit fall-back for unlisted LSMs.
>>>> (i.e. anything missing from lsm.order would then follow their order in
>>>> CONFIG_LSM_ORDER, and anything missing there would fall back to
>>>> link-time ordering.) However, then the objection was raised that this
>>>> didn't provide a way to explicitly disable an LSM. So I proposed
>>>> lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over
>>>> CONFIG_LSM_DISABLE.
>>>
>>> Ok, but it may end up being clearer, simpler, and thus more secure to just
>>> have a single way to configure LSM.
>>>
>>> For example:
>>>
>>>   - All LSMs which are built are NOT enabled by default
>>>
>>>   - You specify enablement and order via a Kconfig:
>>>
>>>         CONFIG_LSM="selinux,yama"
>>>
>>>   - This can be entirely overridden by a boot param:
>>>
>>>         lsm="apparmor,landlock"
>>
>> This doesn't work with how SELinux and AppArmor do their bootparams,
>> unfortunately. (And Paul and Stephen have expressed that the
>> documented selinux on/off must continue to work.) For example, let's
>> say you've built an Ubuntu kernel with:
>>
>> CONFIG_SELINUX=y
>> ...
>> CONFIG_LSM="yama,apparmor"
>>
>> (i.e. you want SELinux available, but not enabled, so it's left out of
>> CONFIG_LSM)
>>
>> Then someone boots the system with:
>>
>> selinux=1 security=selinux
>>
>> In what order does selinux get initialized relative to yama?
>> (apparmor, flagged as a "legacy major", would have been disabled by
>> the "security=" not matching it.)
>>
> 
> To me, "security=selinux" means SELinux and nothing else, so I think that
> all of these params are inviting a lot of confusion.
> 
> Sorry, I don't have a good answer for this.
> 

Your not the only one. I have had users ask about why they are getting
other security messures (yama in particular) when they specified a
specific security=



>>
>> The LSM order needs to be defined externally to enablement because
>> something may become enabled when not listed in the order.
>>
>> Now, maybe I misunderstood your earlier suggestion, and what you meant
>> was to do something like:
>>
>> CONFIG_LSM="yama,apparmor,!selinux"
>>
>> to mean "put selinux here in the order, but don't enable it". Then the
>> problem becomes what happens to an LSM that has been built in but not
>> listed in CONFIG_LSM?
>>
>> Related to that, this means that when new LSMs are added, they will
>> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
>> that's really how we have to go, I'll accept it, but I think it's a
>> bit unfriendly. :P
>>
>> Another reason I don't like it is because it requires users to know
>> about all the LSMs to make changes. One LSM can't be added/removed
>> without specifying ALL of the LSMs. (i.e. there is no trivial way to
>> enable/disable a single LSM without it growing its own enable/disable
>> code as in SELinux/AppArmor. I'd hoped to make that easier for both
>> users and developers.) Again, I can live with it, but I think it's
>> unfriendly.
>>
>> I just want to have a direct I can go that meets all the requirements.
>> :) I'm fine to ignore my sense of aesthetics if everyone can agree on
>> the code.
> 
> 

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04  5:38                               ` John Johansen
  2018-10-04  5:38                                 ` John Johansen
@ 2018-10-04 16:02                                 ` Kees Cook
  2018-10-04 16:02                                   ` Kees Cook
  2018-10-08 14:25                                 ` Paul Moore
  2 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-04 16:02 UTC (permalink / raw)
  To: John Johansen
  Cc: Stephen Smalley, James Morris, Jordan Glover, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 10:38 PM, John Johansen
<john.johansen@canonical.com> wrote:
> but distinct of first exclusive (major) will likely be going away
> once full lsm stacking land.

Right -- then policy loading because the "enabled" flag. The point is
to get us to where we don't care about exclusivity at all.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04 16:02                                 ` Kees Cook
@ 2018-10-04 16:02                                   ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-04 16:02 UTC (permalink / raw)
  To: John Johansen
  Cc: Stephen Smalley, James Morris, Jordan Glover, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, Oct 3, 2018 at 10:38 PM, John Johansen
<john.johansen@canonical.com> wrote:
> but distinct of first exclusive (major) will likely be going away
> once full lsm stacking land.

Right -- then policy loading because the "enabled" flag. The point is
to get us to where we don't care about exclusivity at all.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04  5:56                                   ` John Johansen
  2018-10-04  5:56                                     ` John Johansen
@ 2018-10-04 16:18                                     ` Kees Cook
  2018-10-04 16:18                                       ` Kees Cook
  2018-10-04 17:40                                       ` Jordan Glover
  1 sibling, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-04 16:18 UTC (permalink / raw)
  To: John Johansen, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Wed, Oct 3, 2018 at 10:56 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/03/2018 01:36 PM, Kees Cook wrote:
>> I still think we should have all built LSMs enabled by default, with
>> CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER
>
> and this as a distro ubuntu does not want.
> Ubuntu wants to make yes available by building them in, but does NOT
> want all the LSM enabled by default, not even necessarily all minor LSMs.
>
> As a distro we want a supported set as default, and users can opt-in
> to new LSMs. If a new LSM comes along we don't want it enabled by
> default, which happens Using the lsm disable approach.

Okay, but order still matters. Where, in the order, should a disabled
LSM go? It seems like the friendliest approach for an end-user would
be to do something like

lsm=+landlock

and it all works correctly. That user doesn't need to know about
ordering or the distro default LSMs. They just want to _add_ landlock.
They want all the other LSMs to still be present, and they want the
distro to have chosen where landlock is in the ordering.

>> I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
>> in, since it's just a way to disable all the other majors. I don't
>> like this because it will force LSMs to be disabled that don't need to
>> be once blob-sharing lands. The whole point of this series is to get
>> us away from fixed ordering and thinking about "major" vs "minor" and
>> towards "exclusive" or not, where we can continue to slowly chip away
>> at exclusivity without breaking anything.
>>
> sure we definitely want to get away form "major" vs "minor" and in
> generally even exclusive, except where to LSMs just can't live
> with each other.
>
> But that doesn't mean dropping something like default security. The
> mistake with the current DEFAULT_SECURITY was that it only applied
> to major LSMs, not the minor ones.

Right, we need to expand it to include a full description of ordering
and enablement.

How about this:

CONFIG_LSM specifies order and enablement status. For example:

CONFIG_LSM=yama,loadpin,apparmor,!selinux

This means init order is yama, loadpin, apparmor, selinux, but selinux
is disabled. Anything not listed in CONFIG_LSM but built in will be
disabled and ordered in link-order. (i.e. an implicit trailing
"!smack,!tomoyo".)

Then we add "lsm=" which understands modifiers "-", and "+".
"lsm=-apparmor,+selinux" wouldn't change ordering, but would disable
apparmor and enable selinux. "lsm=smack,loadpin" would enable only
smack and loadpin, in that order and disable everything else.

I don't want to overload "security=", but we can if we want. It would
be as above, but a trailing comma would be needed to trigger the
"ordering" behavior. e.g. "security=selinux" would disable all other
majors (retaining the current behavior), but "security=selinux," would
disable all other LSMs.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04 16:18                                     ` Kees Cook
@ 2018-10-04 16:18                                       ` Kees Cook
  2018-10-04 17:40                                       ` Jordan Glover
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-04 16:18 UTC (permalink / raw)
  To: John Johansen, James Morris
  Cc: Jordan Glover, Stephen Smalley, Paul Moore, Casey Schaufler,
	Tetsuo Handa, Schaufler, Casey, linux-security-module,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Wed, Oct 3, 2018 at 10:56 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/03/2018 01:36 PM, Kees Cook wrote:
>> I still think we should have all built LSMs enabled by default, with
>> CONFIG_LSM_DISABLE available to turn stuff off. CONFIG_LSM_ORDER
>
> and this as a distro ubuntu does not want.
> Ubuntu wants to make yes available by building them in, but does NOT
> want all the LSM enabled by default, not even necessarily all minor LSMs.
>
> As a distro we want a supported set as default, and users can opt-in
> to new LSMs. If a new LSM comes along we don't want it enabled by
> default, which happens Using the lsm disable approach.

Okay, but order still matters. Where, in the order, should a disabled
LSM go? It seems like the friendliest approach for an end-user would
be to do something like

lsm=+landlock

and it all works correctly. That user doesn't need to know about
ordering or the distro default LSMs. They just want to _add_ landlock.
They want all the other LSMs to still be present, and they want the
distro to have chosen where landlock is in the ordering.

>> I should also note that I don't want to leave CONFIG_DEFAULT_SECURITY
>> in, since it's just a way to disable all the other majors. I don't
>> like this because it will force LSMs to be disabled that don't need to
>> be once blob-sharing lands. The whole point of this series is to get
>> us away from fixed ordering and thinking about "major" vs "minor" and
>> towards "exclusive" or not, where we can continue to slowly chip away
>> at exclusivity without breaking anything.
>>
> sure we definitely want to get away form "major" vs "minor" and in
> generally even exclusive, except where to LSMs just can't live
> with each other.
>
> But that doesn't mean dropping something like default security. The
> mistake with the current DEFAULT_SECURITY was that it only applied
> to major LSMs, not the minor ones.

Right, we need to expand it to include a full description of ordering
and enablement.

How about this:

CONFIG_LSM specifies order and enablement status. For example:

CONFIG_LSM=yama,loadpin,apparmor,!selinux

This means init order is yama, loadpin, apparmor, selinux, but selinux
is disabled. Anything not listed in CONFIG_LSM but built in will be
disabled and ordered in link-order. (i.e. an implicit trailing
"!smack,!tomoyo".)

Then we add "lsm=" which understands modifiers "-", and "+".
"lsm=-apparmor,+selinux" wouldn't change ordering, but would disable
apparmor and enable selinux. "lsm=smack,loadpin" would enable only
smack and loadpin, in that order and disable everything else.

I don't want to overload "security=", but we can if we want. It would
be as above, but a trailing comma would be needed to trigger the
"ordering" behavior. e.g. "security=selinux" would disable all other
majors (retaining the current behavior), but "security=selinux," would
disable all other LSMs.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04 16:18                                     ` Kees Cook
  2018-10-04 16:18                                       ` Kees Cook
@ 2018-10-04 17:40                                       ` Jordan Glover
  2018-10-04 17:40                                         ` Jordan Glover
  2018-10-04 17:42                                         ` Kees Cook
  1 sibling, 2 replies; 184+ messages in thread
From: Jordan Glover @ 2018-10-04 17:40 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, James Morris, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, linux-arch, LKML

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 4, 2018 6:18 PM, Kees Cook <keescook@chromium.org> wrote:

>
> I don't want to overload "security=", but we can if we want. It would
> be as above, but a trailing comma would be needed to trigger the
> "ordering" behavior. e.g. "security=selinux" would disable all other
> majors (retaining the current behavior), but "security=selinux," would
> disable all other LSMs.
>
> -Kees
>
>

I don't think giving such big impact to trailing comma is good idea :)

Jordan

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04 17:40                                       ` Jordan Glover
@ 2018-10-04 17:40                                         ` Jordan Glover
  2018-10-04 17:42                                         ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: Jordan Glover @ 2018-10-04 17:40 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, James Morris, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, linux-arch, LKML

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 4, 2018 6:18 PM, Kees Cook <keescook@chromium.org> wrote:

>
> I don't want to overload "security=", but we can if we want. It would
> be as above, but a trailing comma would be needed to trigger the
> "ordering" behavior. e.g. "security=selinux" would disable all other
> majors (retaining the current behavior), but "security=selinux," would
> disable all other LSMs.
>
> -Kees
>
>

I don't think giving such big impact to trailing comma is good idea :)

Jordan

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04 17:40                                       ` Jordan Glover
  2018-10-04 17:40                                         ` Jordan Glover
@ 2018-10-04 17:42                                         ` Kees Cook
  2018-10-04 17:42                                           ` Kees Cook
  1 sibling, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-04 17:42 UTC (permalink / raw)
  To: Jordan Glover
  Cc: John Johansen, James Morris, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, linux-arch, LKML

On Thu, Oct 4, 2018 at 10:40 AM, Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, October 4, 2018 6:18 PM, Kees Cook <keescook@chromium.org> wrote:
>
>>
>> I don't want to overload "security=", but we can if we want. It would
>> be as above, but a trailing comma would be needed to trigger the
>> "ordering" behavior. e.g. "security=selinux" would disable all other
>> majors (retaining the current behavior), but "security=selinux," would
>> disable all other LSMs.
>>
>> -Kees
>>
>>
>
> I don't think giving such big impact to trailing comma is good idea :)

That's why I prefer a new lsm= instead of confusing security=. :)

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04 17:42                                         ` Kees Cook
@ 2018-10-04 17:42                                           ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-04 17:42 UTC (permalink / raw)
  To: Jordan Glover
  Cc: John Johansen, James Morris, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, linux-arch, LKML

On Thu, Oct 4, 2018 at 10:40 AM, Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, October 4, 2018 6:18 PM, Kees Cook <keescook@chromium.org> wrote:
>
>>
>> I don't want to overload "security=", but we can if we want. It would
>> be as above, but a trailing comma would be needed to trigger the
>> "ordering" behavior. e.g. "security=selinux" would disable all other
>> majors (retaining the current behavior), but "security=selinux," would
>> disable all other LSMs.
>>
>> -Kees
>>
>>
>
> I don't think giving such big impact to trailing comma is good idea :)

That's why I prefer a new lsm= instead of confusing security=. :)

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-03 23:55                                   ` Kees Cook
                                                       ` (2 preceding siblings ...)
  2018-10-04  6:18                                     ` John Johansen
@ 2018-10-04 17:49                                     ` James Morris
  2018-10-04 17:49                                       ` James Morris
  2018-10-05  0:05                                       ` Kees Cook
  3 siblings, 2 replies; 184+ messages in thread
From: James Morris @ 2018-10-04 17:49 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, 3 Oct 2018, Kees Cook wrote:

> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> >   - All LSMs which are built are NOT enabled by default
> >
> >   - You specify enablement and order via a Kconfig:
> >
> >         CONFIG_LSM="selinux,yama"
> >
> >   - This can be entirely overridden by a boot param:
> >
> >         lsm="apparmor,landlock"
> 
> This doesn't work with how SELinux and AppArmor do their bootparams,
> unfortunately. (And Paul and Stephen have expressed that the
> documented selinux on/off must continue to work.) For example, let's
> say you've built an Ubuntu kernel with:
> 
> CONFIG_SELINUX=y
> ...
> CONFIG_LSM="yama,apparmor"
> 
> (i.e. you want SELinux available, but not enabled, so it's left out of
> CONFIG_LSM)
> 
> Then someone boots the system with:
> 
> selinux=1 security=selinux
> 
> In what order does selinux get initialized relative to yama?
> (apparmor, flagged as a "legacy major", would have been disabled by
> the "security=" not matching it.)

It doesn't, it needs to be specified in one place.

Distros will need to update boot parameter handling for this kernel 
onwards.  Otherwise, we will need to carry this confusing mess forward 
forever.

> The LSM order needs to be defined externally to enablement because 
> something may become enabled when not listed in the order.
> 
> Now, maybe I misunderstood your earlier suggestion, and what you meant
> was to do something like:
> 
> CONFIG_LSM="yama,apparmor,!selinux"
> 
> to mean "put selinux here in the order, but don't enable it". Then the
> problem becomes what happens to an LSM that has been built in but not
> listed in CONFIG_LSM?

In my most recent suggestion, there is no '!' disablement, just 
enablement.  If an LSM is not listed in CONFIG_LSM="", it's not enabled.

> Related to that, this means that when new LSMs are added, they will
> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
> that's really how we have to go, I'll accept it, but I think it's a
> bit unfriendly. :P

If you want to enable them, yes.  How is this different to adding new 
mount options as new fs features become available?


> Another reason I don't like it is because it requires users to know
> about all the LSMs to make changes. One LSM can't be added/removed
> without specifying ALL of the LSMs. (i.e. there is no trivial way to
> enable/disable a single LSM without it growing its own enable/disable
> code as in SELinux/AppArmor. I'd hoped to make that easier for both
> users and developers.) Again, I can live with it, but I think it's
> unfriendly.

This is only done via boot params or KConfig.

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04 17:49                                     ` James Morris
@ 2018-10-04 17:49                                       ` James Morris
  2018-10-05  0:05                                       ` Kees Cook
  1 sibling, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-04 17:49 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Wed, 3 Oct 2018, Kees Cook wrote:

> On Wed, Oct 3, 2018 at 2:34 PM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >
> >   - All LSMs which are built are NOT enabled by default
> >
> >   - You specify enablement and order via a Kconfig:
> >
> >         CONFIG_LSM="selinux,yama"
> >
> >   - This can be entirely overridden by a boot param:
> >
> >         lsm="apparmor,landlock"
> 
> This doesn't work with how SELinux and AppArmor do their bootparams,
> unfortunately. (And Paul and Stephen have expressed that the
> documented selinux on/off must continue to work.) For example, let's
> say you've built an Ubuntu kernel with:
> 
> CONFIG_SELINUX=y
> ...
> CONFIG_LSM="yama,apparmor"
> 
> (i.e. you want SELinux available, but not enabled, so it's left out of
> CONFIG_LSM)
> 
> Then someone boots the system with:
> 
> selinux=1 security=selinux
> 
> In what order does selinux get initialized relative to yama?
> (apparmor, flagged as a "legacy major", would have been disabled by
> the "security=" not matching it.)

It doesn't, it needs to be specified in one place.

Distros will need to update boot parameter handling for this kernel 
onwards.  Otherwise, we will need to carry this confusing mess forward 
forever.

> The LSM order needs to be defined externally to enablement because 
> something may become enabled when not listed in the order.
> 
> Now, maybe I misunderstood your earlier suggestion, and what you meant
> was to do something like:
> 
> CONFIG_LSM="yama,apparmor,!selinux"
> 
> to mean "put selinux here in the order, but don't enable it". Then the
> problem becomes what happens to an LSM that has been built in but not
> listed in CONFIG_LSM?

In my most recent suggestion, there is no '!' disablement, just 
enablement.  If an LSM is not listed in CONFIG_LSM="", it's not enabled.

> Related to that, this means that when new LSMs are added, they will
> need to be added to any custom CONFIG_LSM= or lsm= parameters. If
> that's really how we have to go, I'll accept it, but I think it's a
> bit unfriendly. :P

If you want to enable them, yes.  How is this different to adding new 
mount options as new fs features become available?


> Another reason I don't like it is because it requires users to know
> about all the LSMs to make changes. One LSM can't be added/removed
> without specifying ALL of the LSMs. (i.e. there is no trivial way to
> enable/disable a single LSM without it growing its own enable/disable
> code as in SELinux/AppArmor. I'd hoped to make that easier for both
> users and developers.) Again, I can live with it, but I think it's
> unfriendly.

This is only done via boot params or KConfig.

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04 17:49                                     ` James Morris
  2018-10-04 17:49                                       ` James Morris
@ 2018-10-05  0:05                                       ` Kees Cook
  2018-10-05  0:05                                         ` Kees Cook
  2018-10-05  4:58                                         ` James Morris
  1 sibling, 2 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-05  0:05 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Thu, Oct 4, 2018 at 10:49 AM, James Morris <jmorris@namei.org> wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>> Then someone boots the system with:
>>
>> selinux=1 security=selinux
>>
>> In what order does selinux get initialized relative to yama?
>> (apparmor, flagged as a "legacy major", would have been disabled by
>> the "security=" not matching it.)
>
> It doesn't, it needs to be specified in one place.
>
> Distros will need to update boot parameter handling for this kernel
> onwards.  Otherwise, we will need to carry this confusing mess forward
> forever.

Are you saying that you want to overrule Paul and Stephen about
keeping "selinux=1 secuiryt=selinux" working?

>> CONFIG_LSM="yama,apparmor,!selinux"
>>
>> to mean "put selinux here in the order, but don't enable it". Then the
>> problem becomes what happens to an LSM that has been built in but not
>> listed in CONFIG_LSM?
>
> In my most recent suggestion, there is no '!' disablement, just
> enablement.  If an LSM is not listed in CONFIG_LSM="", it's not enabled.

And a user would need to specify ALL lsms on the "lsm=" line?

What do you think of my latest proposal? It could happily work all
three ways: old boot params and security= work ("selinux=1
security=selinux" keeps working), individual LSM enable/disable works
("lsm=+loadpin"), and full LSM ordering works
("lsm=each,lsm,in,order,here"):

https://lore.kernel.org/lkml/CAGXu5jJJit8bDNvgXaFkuvFPy7NWtJW2oRWFbG-6iWk0+A1qng@mail.gmail.com/

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-05  0:05                                       ` Kees Cook
@ 2018-10-05  0:05                                         ` Kees Cook
  2018-10-05  4:58                                         ` James Morris
  1 sibling, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-05  0:05 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Thu, Oct 4, 2018 at 10:49 AM, James Morris <jmorris@namei.org> wrote:
> On Wed, 3 Oct 2018, Kees Cook wrote:
>> Then someone boots the system with:
>>
>> selinux=1 security=selinux
>>
>> In what order does selinux get initialized relative to yama?
>> (apparmor, flagged as a "legacy major", would have been disabled by
>> the "security=" not matching it.)
>
> It doesn't, it needs to be specified in one place.
>
> Distros will need to update boot parameter handling for this kernel
> onwards.  Otherwise, we will need to carry this confusing mess forward
> forever.

Are you saying that you want to overrule Paul and Stephen about
keeping "selinux=1 secuiryt=selinux" working?

>> CONFIG_LSM="yama,apparmor,!selinux"
>>
>> to mean "put selinux here in the order, but don't enable it". Then the
>> problem becomes what happens to an LSM that has been built in but not
>> listed in CONFIG_LSM?
>
> In my most recent suggestion, there is no '!' disablement, just
> enablement.  If an LSM is not listed in CONFIG_LSM="", it's not enabled.

And a user would need to specify ALL lsms on the "lsm=" line?

What do you think of my latest proposal? It could happily work all
three ways: old boot params and security= work ("selinux=1
security=selinux" keeps working), individual LSM enable/disable works
("lsm=+loadpin"), and full LSM ordering works
("lsm=each,lsm,in,order,here"):

https://lore.kernel.org/lkml/CAGXu5jJJit8bDNvgXaFkuvFPy7NWtJW2oRWFbG-6iWk0+A1qng@mail.gmail.com/

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-05  0:05                                       ` Kees Cook
  2018-10-05  0:05                                         ` Kees Cook
@ 2018-10-05  4:58                                         ` James Morris
  2018-10-05  4:58                                           ` James Morris
                                                             ` (2 more replies)
  1 sibling, 3 replies; 184+ messages in thread
From: James Morris @ 2018-10-05  4:58 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Thu, 4 Oct 2018, Kees Cook wrote:

> On Thu, Oct 4, 2018 at 10:49 AM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >> Then someone boots the system with:
> >>
> >> selinux=1 security=selinux
> >>
> >> In what order does selinux get initialized relative to yama?
> >> (apparmor, flagged as a "legacy major", would have been disabled by
> >> the "security=" not matching it.)
> >
> > It doesn't, it needs to be specified in one place.
> >
> > Distros will need to update boot parameter handling for this kernel
> > onwards.  Otherwise, we will need to carry this confusing mess forward
> > forever.
> 
> Are you saying that you want to overrule Paul and Stephen about
> keeping "selinux=1 secuiryt=selinux" working?

Not overrule, but convince.

At least, deprecate selinux=1 and security=X, but not extend it any 
further.

> > In my most recent suggestion, there is no '!' disablement, just
> > enablement.  If an LSM is not listed in CONFIG_LSM="", it's not enabled.
> 
> And a user would need to specify ALL lsms on the "lsm=" line?
> 

Yes, the ones they want enabled.

> What do you think of my latest proposal? It could happily work all
> three ways: old boot params and security= work ("selinux=1
> security=selinux" keeps working), individual LSM enable/disable works
> ("lsm=+loadpin"), and full LSM ordering works
> ("lsm=each,lsm,in,order,here"):
> 
> https://lore.kernel.org/lkml/CAGXu5jJJit8bDNvgXaFkuvFPy7NWtJW2oRWFbG-6iWk0+A1qng@mail.gmail.com/
> 

I think having something like +yama will still lead to confusion.
Explicitly stating each enabled LSM in order is totally unambiguous.

If people are moving away from the distro defaults, and there is no 
high-level interface to manage this, it seems to me there's a deeper 
issue with the distro.


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-05  4:58                                         ` James Morris
@ 2018-10-05  4:58                                           ` James Morris
  2018-10-05 16:29                                           ` James Morris
  2018-10-05 16:35                                           ` Kees Cook
  2 siblings, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-05  4:58 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Thu, 4 Oct 2018, Kees Cook wrote:

> On Thu, Oct 4, 2018 at 10:49 AM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 3 Oct 2018, Kees Cook wrote:
> >> Then someone boots the system with:
> >>
> >> selinux=1 security=selinux
> >>
> >> In what order does selinux get initialized relative to yama?
> >> (apparmor, flagged as a "legacy major", would have been disabled by
> >> the "security=" not matching it.)
> >
> > It doesn't, it needs to be specified in one place.
> >
> > Distros will need to update boot parameter handling for this kernel
> > onwards.  Otherwise, we will need to carry this confusing mess forward
> > forever.
> 
> Are you saying that you want to overrule Paul and Stephen about
> keeping "selinux=1 secuiryt=selinux" working?

Not overrule, but convince.

At least, deprecate selinux=1 and security=X, but not extend it any 
further.

> > In my most recent suggestion, there is no '!' disablement, just
> > enablement.  If an LSM is not listed in CONFIG_LSM="", it's not enabled.
> 
> And a user would need to specify ALL lsms on the "lsm=" line?
> 

Yes, the ones they want enabled.

> What do you think of my latest proposal? It could happily work all
> three ways: old boot params and security= work ("selinux=1
> security=selinux" keeps working), individual LSM enable/disable works
> ("lsm=+loadpin"), and full LSM ordering works
> ("lsm=each,lsm,in,order,here"):
> 
> https://lore.kernel.org/lkml/CAGXu5jJJit8bDNvgXaFkuvFPy7NWtJW2oRWFbG-6iWk0+A1qng@mail.gmail.com/
> 

I think having something like +yama will still lead to confusion.
Explicitly stating each enabled LSM in order is totally unambiguous.

If people are moving away from the distro defaults, and there is no 
high-level interface to manage this, it seems to me there's a deeper 
issue with the distro.


-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-05  4:58                                         ` James Morris
  2018-10-05  4:58                                           ` James Morris
@ 2018-10-05 16:29                                           ` James Morris
  2018-10-05 16:29                                             ` James Morris
  2018-10-05 16:35                                           ` Kees Cook
  2 siblings, 1 reply; 184+ messages in thread
From: James Morris @ 2018-10-05 16:29 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Fri, 5 Oct 2018, James Morris wrote:

> On Thu, 4 Oct 2018, Kees Cook wrote:

> > And a user would need to specify ALL lsms on the "lsm=" line?
> > 
> 
> Yes, the ones they want enabled.

If they're overriding the kconfig value.

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-05 16:29                                           ` James Morris
@ 2018-10-05 16:29                                             ` James Morris
  0 siblings, 0 replies; 184+ messages in thread
From: James Morris @ 2018-10-05 16:29 UTC (permalink / raw)
  To: Kees Cook
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Fri, 5 Oct 2018, James Morris wrote:

> On Thu, 4 Oct 2018, Kees Cook wrote:

> > And a user would need to specify ALL lsms on the "lsm=" line?
> > 
> 
> Yes, the ones they want enabled.

If they're overriding the kconfig value.

-- 
James Morris
<jmorris@namei.org>

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-05  4:58                                         ` James Morris
  2018-10-05  4:58                                           ` James Morris
  2018-10-05 16:29                                           ` James Morris
@ 2018-10-05 16:35                                           ` Kees Cook
  2018-10-05 16:35                                             ` Kees Cook
  2 siblings, 1 reply; 184+ messages in thread
From: Kees Cook @ 2018-10-05 16:35 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Thu, Oct 4, 2018 at 9:58 PM, James Morris <jmorris@namei.org> wrote:
> On Thu, 4 Oct 2018, Kees Cook wrote:
>
>> On Thu, Oct 4, 2018 at 10:49 AM, James Morris <jmorris@namei.org> wrote:
>> > On Wed, 3 Oct 2018, Kees Cook wrote:
>> >> Then someone boots the system with:
>> >>
>> >> selinux=1 security=selinux
>> >>
>> >> In what order does selinux get initialized relative to yama?
>> >> (apparmor, flagged as a "legacy major", would have been disabled by
>> >> the "security=" not matching it.)
>> >
>> > It doesn't, it needs to be specified in one place.
>> >
>> > Distros will need to update boot parameter handling for this kernel
>> > onwards.  Otherwise, we will need to carry this confusing mess forward
>> > forever.
>>
>> Are you saying that you want to overrule Paul and Stephen about
>> keeping "selinux=1 secuiryt=selinux" working?
>
> Not overrule, but convince.
>
> At least, deprecate selinux=1 and security=X, but not extend it any
> further.

Okay, this is the expectation from me as well. I think my series makes
it work as-is with the new stuff just fine.

>> > In my most recent suggestion, there is no '!' disablement, just
>> > enablement.  If an LSM is not listed in CONFIG_LSM="", it's not enabled.
>>
>> And a user would need to specify ALL lsms on the "lsm=" line?
>>
>
> Yes, the ones they want enabled.
>
>> What do you think of my latest proposal? It could happily work all
>> three ways: old boot params and security= work ("selinux=1
>> security=selinux" keeps working), individual LSM enable/disable works
>> ("lsm=+loadpin"), and full LSM ordering works
>> ("lsm=each,lsm,in,order,here"):
>>
>> https://lore.kernel.org/lkml/CAGXu5jJJit8bDNvgXaFkuvFPy7NWtJW2oRWFbG-6iWk0+A1qng@mail.gmail.com/
>>
>
> I think having something like +yama will still lead to confusion.
> Explicitly stating each enabled LSM in order is totally unambiguous.
>
> If people are moving away from the distro defaults, and there is no
> high-level interface to manage this, it seems to me there's a deeper
> issue with the distro.

Okay. I will adjust the series and send a v5.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-05 16:35                                           ` Kees Cook
@ 2018-10-05 16:35                                             ` Kees Cook
  0 siblings, 0 replies; 184+ messages in thread
From: Kees Cook @ 2018-10-05 16:35 UTC (permalink / raw)
  To: James Morris
  Cc: John Johansen, Jordan Glover, Stephen Smalley, Paul Moore,
	Casey Schaufler, Tetsuo Handa, Schaufler, Casey,
	linux-security-module, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Thu, Oct 4, 2018 at 9:58 PM, James Morris <jmorris@namei.org> wrote:
> On Thu, 4 Oct 2018, Kees Cook wrote:
>
>> On Thu, Oct 4, 2018 at 10:49 AM, James Morris <jmorris@namei.org> wrote:
>> > On Wed, 3 Oct 2018, Kees Cook wrote:
>> >> Then someone boots the system with:
>> >>
>> >> selinux=1 security=selinux
>> >>
>> >> In what order does selinux get initialized relative to yama?
>> >> (apparmor, flagged as a "legacy major", would have been disabled by
>> >> the "security=" not matching it.)
>> >
>> > It doesn't, it needs to be specified in one place.
>> >
>> > Distros will need to update boot parameter handling for this kernel
>> > onwards.  Otherwise, we will need to carry this confusing mess forward
>> > forever.
>>
>> Are you saying that you want to overrule Paul and Stephen about
>> keeping "selinux=1 secuiryt=selinux" working?
>
> Not overrule, but convince.
>
> At least, deprecate selinux=1 and security=X, but not extend it any
> further.

Okay, this is the expectation from me as well. I think my series makes
it work as-is with the new stuff just fine.

>> > In my most recent suggestion, there is no '!' disablement, just
>> > enablement.  If an LSM is not listed in CONFIG_LSM="", it's not enabled.
>>
>> And a user would need to specify ALL lsms on the "lsm=" line?
>>
>
> Yes, the ones they want enabled.
>
>> What do you think of my latest proposal? It could happily work all
>> three ways: old boot params and security= work ("selinux=1
>> security=selinux" keeps working), individual LSM enable/disable works
>> ("lsm=+loadpin"), and full LSM ordering works
>> ("lsm=each,lsm,in,order,here"):
>>
>> https://lore.kernel.org/lkml/CAGXu5jJJit8bDNvgXaFkuvFPy7NWtJW2oRWFbG-6iWk0+A1qng@mail.gmail.com/
>>
>
> I think having something like +yama will still lead to confusion.
> Explicitly stating each enabled LSM in order is totally unambiguous.
>
> If people are moving away from the distro defaults, and there is no
> high-level interface to manage this, it seems to me there's a deeper
> issue with the distro.

Okay. I will adjust the series and send a v5.

-Kees

-- 
Kees Cook
Pixel Security

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-04  5:38                               ` John Johansen
  2018-10-04  5:38                                 ` John Johansen
  2018-10-04 16:02                                 ` Kees Cook
@ 2018-10-08 14:25                                 ` Paul Moore
  2018-10-08 14:25                                   ` Paul Moore
  2 siblings, 1 reply; 184+ messages in thread
From: Paul Moore @ 2018-10-08 14:25 UTC (permalink / raw)
  To: john.johansen, keescook, casey
  Cc: Stephen Smalley, James Morris, Golden_Miller83, penguin-kernel,
	casey.schaufler, linux-security-module, corbet, linux-doc,
	linux-arch, linux-kernel

On Thu, Oct 4, 2018 at 1:38 AM John Johansen
<john.johansen@canonical.com> wrote:
> On 10/03/2018 10:26 AM, Kees Cook wrote:

...

> > Either a distro builds a very specific subset of LSMs, or they build
> > in all LSMs (for the user to choose from). In both cases, they set an
> > explicit order, which defines which exclusive LSM get selected.
>
> and when lsm stacking lands, that exlusive LSM goes away.

FWIW, I still believe in my earlier statements supporting explicitly
enabling LSM stacking via Kconfig.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 184+ messages in thread

* Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter
  2018-10-08 14:25                                 ` Paul Moore
@ 2018-10-08 14:25                                   ` Paul Moore
  0 siblings, 0 replies; 184+ messages in thread
From: Paul Moore @ 2018-10-08 14:25 UTC (permalink / raw)
  To: john.johansen, keescook, casey
  Cc: Stephen Smalley, James Morris, Golden_Miller83, penguin-kernel,
	casey.schaufler, linux-security-module, corbet, linux-doc,
	linux-arch, linux-kernel

On Thu, Oct 4, 2018 at 1:38 AM John Johansen
<john.johansen@canonical.com> wrote:
> On 10/03/2018 10:26 AM, Kees Cook wrote:

...

> > Either a distro builds a very specific subset of LSMs, or they build
> > in all LSMs (for the user to choose from). In both cases, they set an
> > explicit order, which defines which exclusive LSM get selected.
>
> and when lsm stacking lands, that exlusive LSM goes away.

FWIW, I still believe in my earlier statements supporting explicitly
enabling LSM stacking via Kconfig.

-- 
paul moore
www.paul-moore.com

^ permalink raw reply	[flat|nested] 184+ messages in thread

end of thread, other threads:[~2018-10-08 21:38 UTC | newest]

Thread overview: 184+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-02  0:54 [PATCH security-next v4 00/32] LSM: Explict LSM ordering Kees Cook
2018-10-02  0:54 ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 01/32] LSM: Correctly announce start of LSM initialization Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 02/32] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 03/32] LSM: Rename .security_initcall section to .lsm_info Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 04/32] LSM: Remove initcall tracing Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02 21:14   ` James Morris
2018-10-02 21:14     ` James Morris
2018-10-02  0:54 ` [PATCH security-next v4 05/32] LSM: Convert from initcall to struct lsm_info Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 06/32] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02 21:15   ` James Morris
2018-10-02 21:15     ` James Morris
2018-10-02  0:54 ` [PATCH security-next v4 07/32] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02 21:16   ` James Morris
2018-10-02 21:16     ` James Morris
2018-10-02  0:54 ` [PATCH security-next v4 08/32] LSM: Record LSM name in struct lsm_info Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 09/32] LSM: Provide init debugging infrastructure Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02 21:17   ` James Morris
2018-10-02 21:17     ` James Morris
2018-10-02  0:54 ` [PATCH security-next v4 10/32] LSM: Don't ignore initialization failures Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02 21:20   ` James Morris
2018-10-02 21:20     ` James Morris
2018-10-02 21:38     ` Kees Cook
2018-10-02 21:38       ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 11/32] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 12/32] LSM: Provide separate ordered initialization Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 13/32] LoadPin: Rename "enable" to "enforce" Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  1:06   ` Randy Dunlap
2018-10-02  1:06     ` Randy Dunlap
2018-10-02  4:47     ` Kees Cook
2018-10-02  4:47       ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 14/32] LSM: Plumb visibility into optional "enabled" state Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 15/32] LSM: Lift LSM selection out of individual LSMs Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 16/32] LSM: Prepare for arbitrary LSM enabling Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 17/32] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 18/32] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 19/32] LSM: Prepare for reorganizing "security=" logic Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 20/32] LSM: Refactor "security=" in terms of enable/disable Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 21/32] LSM: Finalize centralized LSM enabling logic Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  1:18   ` Randy Dunlap
2018-10-02  1:18     ` Randy Dunlap
2018-10-02  4:49     ` Kees Cook
2018-10-02  4:49       ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 22/32] apparmor: Remove boot parameter Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 23/32] selinux: " Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02 12:12   ` Paul Moore
2018-10-02 12:12     ` Paul Moore
2018-10-02 13:42     ` Stephen Smalley
2018-10-02 13:42       ` Stephen Smalley
2018-10-02 14:44       ` Kees Cook
2018-10-02 14:44         ` Kees Cook
2018-10-02 14:58         ` Stephen Smalley
2018-10-02 14:58           ` Stephen Smalley
2018-10-02 16:33           ` Jordan Glover
2018-10-02 16:33             ` Jordan Glover
2018-10-02 16:54             ` Kees Cook
2018-10-02 16:54               ` Kees Cook
2018-10-02 18:33               ` Stephen Smalley
2018-10-02 18:33                 ` Stephen Smalley
2018-10-02 19:02                 ` Kees Cook
2018-10-02 19:02                   ` Kees Cook
2018-10-02 18:57               ` John Johansen
2018-10-02 18:57                 ` John Johansen
2018-10-02 19:17                 ` Kees Cook
2018-10-02 19:17                   ` Kees Cook
2018-10-02 19:47                   ` John Johansen
2018-10-02 19:47                     ` John Johansen
2018-10-02 20:29                     ` Kees Cook
2018-10-02 20:29                       ` Kees Cook
2018-10-02 21:11                       ` John Johansen
2018-10-02 21:11                         ` John Johansen
2018-10-02 22:06                   ` James Morris
2018-10-02 22:06                     ` James Morris
2018-10-02 23:06                     ` Kees Cook
2018-10-02 23:06                       ` Kees Cook
2018-10-02 23:46                       ` John Johansen
2018-10-02 23:46                         ` John Johansen
2018-10-02 23:54                         ` Kees Cook
2018-10-02 23:54                           ` Kees Cook
2018-10-03  0:05                           ` John Johansen
2018-10-03  0:05                             ` John Johansen
2018-10-03  0:12                             ` Kees Cook
2018-10-03  0:12                               ` Kees Cook
2018-10-03 13:15                               ` John Johansen
2018-10-03 13:15                                 ` John Johansen
2018-10-03 13:39                           ` Stephen Smalley
2018-10-03 13:39                             ` Stephen Smalley
2018-10-03 17:26                             ` Kees Cook
2018-10-03 17:26                               ` Kees Cook
2018-10-03 19:43                               ` Stephen Smalley
2018-10-03 19:43                                 ` Stephen Smalley
2018-10-04  5:38                               ` John Johansen
2018-10-04  5:38                                 ` John Johansen
2018-10-04 16:02                                 ` Kees Cook
2018-10-04 16:02                                   ` Kees Cook
2018-10-08 14:25                                 ` Paul Moore
2018-10-08 14:25                                   ` Paul Moore
2018-10-03 18:17                         ` James Morris
2018-10-03 18:17                           ` James Morris
2018-10-03 18:20                           ` Kees Cook
2018-10-03 18:20                             ` Kees Cook
2018-10-03 18:28                             ` James Morris
2018-10-03 18:28                               ` James Morris
2018-10-03 20:10                               ` Kees Cook
2018-10-03 20:10                                 ` Kees Cook
2018-10-03 20:36                                 ` Kees Cook
2018-10-03 20:36                                   ` Kees Cook
2018-10-03 21:19                                   ` James Morris
2018-10-03 21:19                                     ` James Morris
2018-10-04  5:56                                   ` John Johansen
2018-10-04  5:56                                     ` John Johansen
2018-10-04 16:18                                     ` Kees Cook
2018-10-04 16:18                                       ` Kees Cook
2018-10-04 17:40                                       ` Jordan Glover
2018-10-04 17:40                                         ` Jordan Glover
2018-10-04 17:42                                         ` Kees Cook
2018-10-04 17:42                                           ` Kees Cook
2018-10-03 21:34                                 ` James Morris
2018-10-03 21:34                                   ` James Morris
2018-10-03 23:55                                   ` Kees Cook
2018-10-03 23:55                                     ` Kees Cook
2018-10-03 23:59                                     ` Randy Dunlap
2018-10-03 23:59                                       ` Randy Dunlap
2018-10-04  0:03                                       ` Kees Cook
2018-10-04  0:03                                         ` Kees Cook
2018-10-04  6:22                                       ` John Johansen
2018-10-04  6:22                                         ` John Johansen
2018-10-04  6:18                                     ` John Johansen
2018-10-04  6:18                                       ` John Johansen
2018-10-04 17:49                                     ` James Morris
2018-10-04 17:49                                       ` James Morris
2018-10-05  0:05                                       ` Kees Cook
2018-10-05  0:05                                         ` Kees Cook
2018-10-05  4:58                                         ` James Morris
2018-10-05  4:58                                           ` James Morris
2018-10-05 16:29                                           ` James Morris
2018-10-05 16:29                                             ` James Morris
2018-10-05 16:35                                           ` Kees Cook
2018-10-05 16:35                                             ` Kees Cook
2018-10-02 23:28                     ` John Johansen
2018-10-02 23:28                       ` John Johansen
2018-10-02 16:34           ` Kees Cook
2018-10-02 16:34             ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 24/32] LSM: Build ordered list of ordered LSMs for init Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 25/32] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:54 ` [PATCH security-next v4 26/32] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
2018-10-02  0:54   ` Kees Cook
2018-10-02  0:55 ` [PATCH security-next v4 27/32] LoadPin: Initialize as ordered LSM Kees Cook
2018-10-02  0:55   ` Kees Cook
2018-10-02  0:55 ` [PATCH security-next v4 28/32] Yama: " Kees Cook
2018-10-02  0:55   ` Kees Cook
2018-10-02  0:55 ` [PATCH security-next v4 29/32] LSM: Introduce enum lsm_order Kees Cook
2018-10-02  0:55   ` Kees Cook
2018-10-02  0:55 ` [PATCH security-next v4 30/32] capability: Initialize as LSM_ORDER_FIRST Kees Cook
2018-10-02  0:55   ` Kees Cook
2018-10-02  0:55 ` [PATCH security-next v4 31/32] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
2018-10-02  0:55   ` Kees Cook
2018-10-02  0:55 ` [PATCH security-next v4 32/32] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
2018-10-02  0:55   ` 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).