linux-arch.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH security-next v3 00/29] LSM: Explict LSM ordering
@ 2018-09-25  0:18 Kees Cook
  2018-09-25  0:18 ` Kees Cook
                   ` (30 more replies)
  0 siblings, 31 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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

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

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         |  20 +
 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                     |  43 ++-
 include/linux/module.h                        |   1 -
 security/Kconfig                              |  61 ++-
 security/apparmor/lsm.c                       |  16 +-
 security/commoncap.c                          |   8 +-
 security/integrity/iint.c                     |   5 +-
 security/loadpin/Kconfig                      |   4 +-
 security/loadpin/loadpin.c                    |  28 +-
 security/security.c                           | 351 +++++++++++++++---
 security/selinux/hooks.c                      |  16 +-
 security/smack/smack_lsm.c                    |   8 +-
 security/tomoyo/tomoyo.c                      |   7 +-
 security/yama/yama_lsm.c                      |   7 +-
 24 files changed, 438 insertions(+), 175 deletions(-)

-- 
2.17.1

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

* [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization Kees Cook
                   ` (29 subsequent siblings)
  30 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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

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

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         |  20 +
 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                     |  43 ++-
 include/linux/module.h                        |   1 -
 security/Kconfig                              |  61 ++-
 security/apparmor/lsm.c                       |  16 +-
 security/commoncap.c                          |   8 +-
 security/integrity/iint.c                     |   5 +-
 security/loadpin/Kconfig                      |   4 +-
 security/loadpin/loadpin.c                    |  28 +-
 security/security.c                           | 351 +++++++++++++++---
 security/selinux/hooks.c                      |  16 +-
 security/smack/smack_lsm.c                    |   8 +-
 security/tomoyo/tomoyo.c                      |   7 +-
 security/yama/yama_lsm.c                      |   7 +-
 24 files changed, 438 insertions(+), 175 deletions(-)

-- 
2.17.1

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

* [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
  2018-09-25  0:18 ` Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
                     ` (2 more replies)
  2018-09-25  0:18 ` [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
                   ` (28 subsequent siblings)
  30 siblings, 3 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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] 164+ messages in thread

* [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization
  2018-09-25  0:18 ` [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 19:53   ` James Morris
  2018-10-01 21:05   ` John Johansen
  2 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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] 164+ messages in thread

* [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
  2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
                     ` (2 more replies)
  2018-09-25  0:18 ` [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info Kees Cook
                   ` (27 subsequent siblings)
  30 siblings, 3 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Arnd Bergmann, linux-arch, Casey Schaufler,
	John Johansen, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-kernel

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

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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] 164+ messages in thread

* [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section
  2018-09-25  0:18 ` [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 19:56   ` James Morris
  2018-10-01 21:05   ` John Johansen
  2 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Arnd Bergmann, linux-arch, Casey Schaufler,
	John Johansen, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-kernel

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

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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] 164+ messages in thread

* [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (2 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
                     ` (2 more replies)
  2018-09-25  0:18 ` [PATCH security-next v3 04/29] LSM: Remove initcall tracing Kees Cook
                   ` (26 subsequent siblings)
  30 siblings, 3 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Arnd Bergmann, Serge E. Hallyn, Ard Biesheuvel,
	linux-arch, linux-security-module, Casey Schaufler,
	John Johansen, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, Jonathan Corbet, linux-doc, linux-kernel

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

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-arch@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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] 164+ messages in thread

* [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info
  2018-09-25  0:18 ` [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 19:57   ` James Morris
  2018-10-01 21:06   ` John Johansen
  2 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Arnd Bergmann, Serge E. Hallyn, Ard Biesheuvel,
	linux-arch, linux-security-module, Casey Schaufler,
	John Johansen, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, Jonathan Corbet, linux-doc, linux-kernel

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

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: linux-arch@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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] 164+ messages in thread

* [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (3 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
                     ` (2 more replies)
  2018-09-25  0:18 ` [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info Kees Cook
                   ` (25 subsequent siblings)
  30 siblings, 3 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Serge E. Hallyn, Abderrahmane Benbachir,
	Steven Rostedt, linux-security-module, Casey Schaufler,
	John Johansen, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, 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.

Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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] 164+ messages in thread

* [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-25  0:18 ` [PATCH security-next v3 04/29] LSM: Remove initcall tracing Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-09-26 16:35   ` Steven Rostedt
  2018-10-01 21:07   ` John Johansen
  2 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Serge E. Hallyn, Abderrahmane Benbachir,
	Steven Rostedt, linux-security-module, Casey Schaufler,
	John Johansen, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, 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.

Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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] 164+ messages in thread

* [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (4 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 04/29] LSM: Remove initcall tracing Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
                     ` (2 more replies)
  2018-09-25  0:18 ` [PATCH security-next v3 06/29] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
                   ` (24 subsequent siblings)
  30 siblings, 3 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Serge E. Hallyn, Ard Biesheuvel, Paul Moore,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Stephen Smalley, Schaufler, Casey, 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.

Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Paul Moore <paul@paul-moore.com>
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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..ad04761e5587 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);
+};
+
+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] 164+ messages in thread

* [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info
  2018-09-25  0:18 ` [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 19:59   ` James Morris
  2018-10-01 21:08   ` John Johansen
  2 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, Serge E. Hallyn, Ard Biesheuvel, Paul Moore,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Stephen Smalley, Schaufler, Casey, 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.

Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Paul Moore <paul@paul-moore.com>
Cc: linux-security-module@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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..ad04761e5587 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);
+};
+
+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] 164+ messages in thread

* [PATCH security-next v3 06/29] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (5 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:10   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
                   ` (23 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, linux-arch, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, 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.

Cc: linux-arch@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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] 164+ messages in thread

* [PATCH security-next v3 06/29] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA
  2018-09-25  0:18 ` [PATCH security-next v3 06/29] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:10   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, linux-arch, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, 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.

Cc: linux-arch@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 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] 164+ messages in thread

* [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM()
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (6 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 06/29] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:12   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info Kees Cook
                   ` (22 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, John Johansen, Serge E. Hallyn, Paul Moore,
	Stephen Smalley, Casey Schaufler, Tetsuo Handa, Mimi Zohar,
	linux-security-module, selinux, Tetsuo Handa, Schaufler, Casey,
	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.

Cc: John Johansen <john.johansen@canonical.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Casey Schaufler <casey@schaufler-ca.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux-security-module@vger.kernel.org
Cc: selinux@tycho.nsa.gov
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/lsm_hooks.h  | 6 ++++--
 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, 19 insertions(+), 7 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index ad04761e5587..02ec717189f9 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2045,11 +2045,13 @@ 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, }
+		= {							\
+
+#define END_LSM	  }
 
 #ifdef CONFIG_SECURITY_SELINUX_DISABLE
 /*
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 8b8b70620bbe..7fa7b4464cf4 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,
+END_LSM;
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 70d21b566955..20e60df929a3 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,
+END_LSM;
 
 
 /*
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index ad9a9b8e9979..469a90806bc6 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,
+END_LSM;
 
 #if defined(CONFIG_NETFILTER)
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 340fc30ad85d..1e1ace718e75 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,
+END_LSM;
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 9f932e2d6852..a280d4eab456 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,
+END_LSM;
-- 
2.17.1

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

* [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM()
  2018-09-25  0:18 ` [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:12   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, John Johansen, Serge E. Hallyn, Paul Moore,
	Stephen Smalley, Casey Schaufler, Tetsuo Handa, Mimi Zohar,
	linux-security-module, selinux, Tetsuo Handa, Schaufler, Casey,
	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.

Cc: John Johansen <john.johansen@canonical.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Casey Schaufler <casey@schaufler-ca.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux-security-module@vger.kernel.org
Cc: selinux@tycho.nsa.gov
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/lsm_hooks.h  | 6 ++++--
 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, 19 insertions(+), 7 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index ad04761e5587..02ec717189f9 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2045,11 +2045,13 @@ 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, }
+		= {							\
+
+#define END_LSM	  }
 
 #ifdef CONFIG_SECURITY_SELINUX_DISABLE
 /*
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 8b8b70620bbe..7fa7b4464cf4 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,
+END_LSM;
diff --git a/security/integrity/iint.c b/security/integrity/iint.c
index 70d21b566955..20e60df929a3 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,
+END_LSM;
 
 
 /*
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index ad9a9b8e9979..469a90806bc6 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,
+END_LSM;
 
 #if defined(CONFIG_NETFILTER)
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 340fc30ad85d..1e1ace718e75 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,
+END_LSM;
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 9f932e2d6852..a280d4eab456 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,
+END_LSM;
-- 
2.17.1

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

* [PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (7 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:13   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 09/29] LSM: Provide init debugging infrastructure Kees Cook
                   ` (21 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, James Morris, 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.

Cc: James Morris <james.morris@microsoft.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/lsm_hooks.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 02ec717189f9..543636f18152 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2040,16 +2040,20 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
 struct lsm_info {
+	const char *name;	/* Populated automatically. */
 	int (*init)(void);
 };
 
 extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
 
 #define DEFINE_LSM(lsm)							\
+	static const char __lsm_name_##lsm[] __initconst		\
+		__aligned(1) = #lsm;					\
 	static struct lsm_info __lsm_##lsm				\
 		__used __section(.lsm_info.init)			\
 		__aligned(sizeof(unsigned long))			\
 		= {							\
+			.name = __lsm_name_##lsm,			\
 
 #define END_LSM	  }
 
-- 
2.17.1

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

* [PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info
  2018-09-25  0:18 ` [PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:13   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 UTC (permalink / raw)
  To: James Morris
  Cc: Kees Cook, James Morris, 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.

Cc: James Morris <james.morris@microsoft.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/lsm_hooks.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 02ec717189f9..543636f18152 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2040,16 +2040,20 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 				char *lsm);
 
 struct lsm_info {
+	const char *name;	/* Populated automatically. */
 	int (*init)(void);
 };
 
 extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
 
 #define DEFINE_LSM(lsm)							\
+	static const char __lsm_name_##lsm[] __initconst		\
+		__aligned(1) = #lsm;					\
 	static struct lsm_info __lsm_##lsm				\
 		__used __section(.lsm_info.init)			\
 		__aligned(sizeof(unsigned long))			\
 		= {							\
+			.name = __lsm_name_##lsm,			\
 
 #define END_LSM	  }
 
-- 
2.17.1

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

* [PATCH security-next v3 09/29] LSM: Provide init debugging infrastructure
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (8 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:14   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 10/29] LSM: Don't ignore initialization failures Kees Cook
                   ` (20 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 .../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..ee49b921d750 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 bool debug __initdata;
+#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] 164+ messages in thread

* [PATCH security-next v3 09/29] LSM: Provide init debugging infrastructure
  2018-09-25  0:18 ` [PATCH security-next v3 09/29] LSM: Provide init debugging infrastructure Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:14   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 .../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..ee49b921d750 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 bool debug __initdata;
+#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] 164+ messages in thread

* [PATCH security-next v3 10/29] LSM: Don't ignore initialization failures
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (9 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 09/29] LSM: Provide init debugging infrastructure Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:14   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
                   ` (19 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security/security.c b/security/security.c
index ee49b921d750..1f055936a746 100644
--- a/security/security.c
+++ b/security/security.c
@@ -55,10 +55,12 @@ static bool debug __initdata;
 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] 164+ messages in thread

* [PATCH security-next v3 10/29] LSM: Don't ignore initialization failures
  2018-09-25  0:18 ` [PATCH security-next v3 10/29] LSM: Don't ignore initialization failures Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:14   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/security/security.c b/security/security.c
index ee49b921d750..1f055936a746 100644
--- a/security/security.c
+++ b/security/security.c
@@ -55,10 +55,12 @@ static bool debug __initdata;
 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] 164+ messages in thread

* [PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (10 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 10/29] LSM: Don't ignore initialization failures Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:15   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization Kees Cook
                   ` (18 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 543636f18152..5056f7374b3d 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;	/* Populated automatically. */
+	unsigned long flags;	/* Optional: flags describing LSM */
 	int (*init)(void);
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 7fa7b4464cf4..4c5f63e9aeba 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1607,5 +1607,6 @@ static int __init apparmor_init(void)
 }
 
 DEFINE_LSM(apparmor)
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = apparmor_init,
 END_LSM;
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 469a90806bc6..615cf6498c0f 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)
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = selinux_init,
 END_LSM;
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 1e1ace718e75..4aef844fc0e2 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)
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = smack_init,
 END_LSM;
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index a280d4eab456..528b6244a648 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -551,5 +551,6 @@ static int __init tomoyo_init(void)
 }
 
 DEFINE_LSM(tomoyo)
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = tomoyo_init,
 END_LSM;
-- 
2.17.1

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

* [PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR
  2018-09-25  0:18 ` [PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:15   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 543636f18152..5056f7374b3d 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;	/* Populated automatically. */
+	unsigned long flags;	/* Optional: flags describing LSM */
 	int (*init)(void);
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 7fa7b4464cf4..4c5f63e9aeba 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1607,5 +1607,6 @@ static int __init apparmor_init(void)
 }
 
 DEFINE_LSM(apparmor)
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = apparmor_init,
 END_LSM;
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 469a90806bc6..615cf6498c0f 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)
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = selinux_init,
 END_LSM;
 
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 1e1ace718e75..4aef844fc0e2 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)
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = smack_init,
 END_LSM;
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index a280d4eab456..528b6244a648 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -551,5 +551,6 @@ static int __init tomoyo_init(void)
 }
 
 DEFINE_LSM(tomoyo)
+	.flags = LSM_FLAG_LEGACY_MAJOR,
 	.init = tomoyo_init,
 END_LSM;
-- 
2.17.1

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

* [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (11 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:17   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce" Kees Cook
                   ` (17 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/security/security.c b/security/security.c
index 1f055936a746..a886a978214a 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,12 +52,30 @@ static bool debug __initdata;
 			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] 164+ messages in thread

* [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization
  2018-09-25  0:18 ` [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:17   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/security/security.c b/security/security.c
index 1f055936a746..a886a978214a 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,12 +52,30 @@ static bool debug __initdata;
 			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] 164+ messages in thread

* [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce"
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (12 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:17   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state Kees Cook
                   ` (16 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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] 164+ messages in thread

* [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce"
  2018-09-25  0:18 ` [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce" Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:17   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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] 164+ messages in thread

* [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (13 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce" Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
                     ` (2 more replies)
  2018-09-25  0:18 ` [PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs Kees Cook
                   ` (15 subsequent siblings)
  30 siblings, 3 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 5056f7374b3d..2a41e8e6f6e5 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;	/* Populated automatically. */
 	unsigned long flags;	/* Optional: flags describing LSM */
+	int *enabled;		/* Optional: NULL means enabled. */
 	int (*init)(void);
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 4c5f63e9aeba..d03133a267f2 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)
 {
@@ -1608,5 +1608,6 @@ static int __init apparmor_init(void)
 
 DEFINE_LSM(apparmor)
 	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.enabled = &apparmor_enabled,
 	.init = apparmor_init,
 END_LSM;
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 615cf6498c0f..3f999ed98cfd 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)
 	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.enabled = &selinux_enabled,
 	.init = selinux_init,
 END_LSM;
 
-- 
2.17.1

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

* [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-09-25  0:18 ` [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:18   ` John Johansen
  2018-10-01 21:47   ` James Morris
  2 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 5056f7374b3d..2a41e8e6f6e5 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;	/* Populated automatically. */
 	unsigned long flags;	/* Optional: flags describing LSM */
+	int *enabled;		/* Optional: NULL means enabled. */
 	int (*init)(void);
 };
 
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 4c5f63e9aeba..d03133a267f2 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)
 {
@@ -1608,5 +1608,6 @@ static int __init apparmor_init(void)
 
 DEFINE_LSM(apparmor)
 	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.enabled = &apparmor_enabled,
 	.init = apparmor_init,
 END_LSM;
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 615cf6498c0f..3f999ed98cfd 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)
 	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.enabled = &selinux_enabled,
 	.init = selinux_init,
 END_LSM;
 
-- 
2.17.1

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

* [PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (14 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:18   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling Kees Cook
                   ` (14 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 2a41e8e6f6e5..95798f212dbf 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2091,7 +2091,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 d03133a267f2..5399c2f03536 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 a886a978214a..056b36cf6245 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,33 +52,78 @@ static bool debug __initdata;
 			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 3f999ed98cfd..409a9252aeb6 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 4aef844fc0e2..e79fad43a8e3 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 528b6244a648..39bb994ebe09 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] 164+ messages in thread

* [PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs
  2018-09-25  0:18 ` [PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:18   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 2a41e8e6f6e5..95798f212dbf 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2091,7 +2091,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 d03133a267f2..5399c2f03536 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 a886a978214a..056b36cf6245 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,33 +52,78 @@ static bool debug __initdata;
 			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 3f999ed98cfd..409a9252aeb6 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 4aef844fc0e2..e79fad43a8e3 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 528b6244a648..39bb994ebe09 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] 164+ messages in thread

* [PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (15 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:22   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
                   ` (13 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 69 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git a/security/security.c b/security/security.c
index 056b36cf6245..a8107d54b3d3 100644
--- a/security/security.c
+++ b/security/security.c
@@ -54,17 +54,46 @@ static bool debug __initdata;
 
 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] 164+ messages in thread

* [PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling
  2018-09-25  0:18 ` [PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:22   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 69 ++++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 65 insertions(+), 4 deletions(-)

diff --git a/security/security.c b/security/security.c
index 056b36cf6245..a8107d54b3d3 100644
--- a/security/security.c
+++ b/security/security.c
@@ -54,17 +54,46 @@ static bool debug __initdata;
 
 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] 164+ messages in thread

* [PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (16 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:34   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
                   ` (12 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 95798f212dbf..ab23f1bc6d77 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;	/* Populated automatically. */
 	unsigned long flags;	/* Optional: flags describing LSM */
-	int *enabled;		/* Optional: NULL means enabled. */
+	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
 	int (*init)(void);
 };
 
diff --git a/security/Kconfig b/security/Kconfig
index 27d8b2688f75..71306b046270 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-separate 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 a8107d54b3d3..7ecb9879a863 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 bool debug __initdata;
 #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] 164+ messages in thread

* [PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE
  2018-09-25  0:18 ` [PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:34   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 95798f212dbf..ab23f1bc6d77 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;	/* Populated automatically. */
 	unsigned long flags;	/* Optional: flags describing LSM */
-	int *enabled;		/* Optional: NULL means enabled. */
+	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
 	int (*init)(void);
 };
 
diff --git a/security/Kconfig b/security/Kconfig
index 27d8b2688f75..71306b046270 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-separate 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 a8107d54b3d3..7ecb9879a863 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 bool debug __initdata;
 #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] 164+ messages in thread

* [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (17 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:46   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic Kees Cook
                   ` (11 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 .../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 71306b046270..1a82a006cc62 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -282,7 +282,9 @@ config LSM_ENABLE
 	help
 	  A comma-separate 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 7ecb9879a863..456a3f73bc36 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] 164+ messages in thread

* [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-09-25  0:18 ` [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:46   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 .../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 71306b046270..1a82a006cc62 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -282,7 +282,9 @@ config LSM_ENABLE
 	help
 	  A comma-separate 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 7ecb9879a863..456a3f73bc36 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] 164+ messages in thread

* [PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (18 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:47   ` John Johansen
  2018-09-25  0:18 ` [PATCH security-next v3 20/29] LSM: Refactor "security=" in terms of enable/disable Kees Cook
                   ` (10 subsequent siblings)
  30 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/security/security.c b/security/security.c
index 456a3f73bc36..e325fcc41f00 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] 164+ messages in thread

* [PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic
  2018-09-25  0:18 ` [PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:47   ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 17 ++++++++---------
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/security/security.c b/security/security.c
index 456a3f73bc36..e325fcc41f00 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] 164+ messages in thread

* [PATCH security-next v3 20/29] LSM: Refactor "security=" in terms of enable/disable
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (19 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 21/29] LSM: Build ordered list of ordered LSMs for init Kees Cook
                   ` (9 subsequent siblings)
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/security/security.c b/security/security.c
index e325fcc41f00..a98549b334af 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] 164+ messages in thread

* [PATCH security-next v3 20/29] LSM: Refactor "security=" in terms of enable/disable
  2018-09-25  0:18 ` [PATCH security-next v3 20/29] LSM: Refactor "security=" in terms of enable/disable Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 24 ++++++++++++++++--------
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/security/security.c b/security/security.c
index e325fcc41f00..a98549b334af 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] 164+ messages in thread

* [PATCH security-next v3 21/29] LSM: Build ordered list of ordered LSMs for init
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (20 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 20/29] LSM: Refactor "security=" in terms of enable/disable Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 22/29] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
                   ` (8 subsequent siblings)
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 59 +++++++++++++++++++++++++++++++++++++++------
 1 file changed, 52 insertions(+), 7 deletions(-)

diff --git a/security/security.c b/security/security.c
index a98549b334af..ef1ced0a3a50 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 bool debug __initdata;
 #define init_debug(...)						\
 	do {							\
@@ -96,6 +102,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)
 {
@@ -126,14 +171,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)
@@ -215,6 +256,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();
@@ -227,6 +270,7 @@ int __init security_init(void)
 	loadpin_add_hooks();
 
 	/* Load LSMs in specified order. */
+	prepare_lsm_order();
 	ordered_lsm_init();
 
 	/*
@@ -234,6 +278,7 @@ int __init security_init(void)
 	 */
 	major_lsm_init();
 
+	kfree(ordered_lsms);
 	return 0;
 }
 
-- 
2.17.1

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

* [PATCH security-next v3 21/29] LSM: Build ordered list of ordered LSMs for init
  2018-09-25  0:18 ` [PATCH security-next v3 21/29] LSM: Build ordered list of ordered LSMs for init Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/security.c | 59 +++++++++++++++++++++++++++++++++++++++------
 1 file changed, 52 insertions(+), 7 deletions(-)

diff --git a/security/security.c b/security/security.c
index a98549b334af..ef1ced0a3a50 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 bool debug __initdata;
 #define init_debug(...)						\
 	do {							\
@@ -96,6 +102,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)
 {
@@ -126,14 +171,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)
@@ -215,6 +256,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();
@@ -227,6 +270,7 @@ int __init security_init(void)
 	loadpin_add_hooks();
 
 	/* Load LSMs in specified order. */
+	prepare_lsm_order();
 	ordered_lsm_init();
 
 	/*
@@ -234,6 +278,7 @@ int __init security_init(void)
 	 */
 	major_lsm_init();
 
+	kfree(ordered_lsms);
 	return 0;
 }
 
-- 
2.17.1

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

* [PATCH security-next v3 22/29] LSM: Introduce CONFIG_LSM_ORDER
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (21 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 21/29] LSM: Build ordered list of ordered LSMs for init Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 23/29] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
                   ` (7 subsequent siblings)
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/Kconfig    | 16 ++++++++++++++++
 security/security.c | 40 +++++++++++++++++++++++++++++++++++++---
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 1a82a006cc62..7ec86dbdb6b8 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 ef1ced0a3a50..e38df0314f5e 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;
@@ -130,14 +131,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] 164+ messages in thread

* [PATCH security-next v3 22/29] LSM: Introduce CONFIG_LSM_ORDER
  2018-09-25  0:18 ` [PATCH security-next v3 22/29] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/Kconfig    | 16 ++++++++++++++++
 security/security.c | 40 +++++++++++++++++++++++++++++++++++++---
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 1a82a006cc62..7ec86dbdb6b8 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 ef1ced0a3a50..e38df0314f5e 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;
@@ -130,14 +131,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] 164+ messages in thread

* [PATCH security-next v3 23/29] LSM: Introduce "lsm.order=" for boottime ordering
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (22 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 22/29] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 24/29] LoadPin: Initialize as ordered LSM Kees Cook
                   ` (6 subsequent siblings)
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 67c90985d2b8..c7c1a0d253ee 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2288,6 +2288,12 @@
 			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
 			boot parameters.
 
+	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 e38df0314f5e..f1c3581d870f 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;
@@ -160,11 +161,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");
 
@@ -324,6 +328,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] 164+ messages in thread

* [PATCH security-next v3 23/29] LSM: Introduce "lsm.order=" for boottime ordering
  2018-09-25  0:18 ` [PATCH security-next v3 23/29] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 67c90985d2b8..c7c1a0d253ee 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2288,6 +2288,12 @@
 			CONFIG_LSM_ENABLE, and any per-LSM CONFIGs and
 			boot parameters.
 
+	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 e38df0314f5e..f1c3581d870f 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;
@@ -160,11 +161,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");
 
@@ -324,6 +328,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] 164+ messages in thread

* [PATCH security-next v3 24/29] LoadPin: Initialize as ordered LSM
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (23 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 23/29] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 25/29] Yama: " Kees Cook
                   ` (5 subsequent siblings)
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 include/linux/lsm_hooks.h  | 5 -----
 security/Kconfig           | 2 +-
 security/loadpin/loadpin.c | 7 ++++++-
 security/security.c        | 1 -
 4 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index ab23f1bc6d77..9df08955f684 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2097,10 +2097,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 7ec86dbdb6b8..e20c2a3143e7 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..7abdf4619b46 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -184,13 +184,18 @@ 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)
+	.init = loadpin_init,
+END_LSM;
+
 /* 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 f1c3581d870f..cb25f321e044 100644
--- a/security/security.c
+++ b/security/security.c
@@ -305,7 +305,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] 164+ messages in thread

* [PATCH security-next v3 24/29] LoadPin: Initialize as ordered LSM
  2018-09-25  0:18 ` [PATCH security-next v3 24/29] LoadPin: Initialize as ordered LSM Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 include/linux/lsm_hooks.h  | 5 -----
 security/Kconfig           | 2 +-
 security/loadpin/loadpin.c | 7 ++++++-
 security/security.c        | 1 -
 4 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index ab23f1bc6d77..9df08955f684 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2097,10 +2097,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 7ec86dbdb6b8..e20c2a3143e7 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..7abdf4619b46 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -184,13 +184,18 @@ 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)
+	.init = loadpin_init,
+END_LSM;
+
 /* 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 f1c3581d870f..cb25f321e044 100644
--- a/security/security.c
+++ b/security/security.c
@@ -305,7 +305,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] 164+ messages in thread

* [PATCH security-next v3 25/29] Yama: Initialize as ordered LSM
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (24 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 24/29] LoadPin: Initialize as ordered LSM Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 26/29] LSM: Introduce enum lsm_order Kees Cook
                   ` (4 subsequent siblings)
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 include/linux/lsm_hooks.h | 5 -----
 security/Kconfig          | 2 +-
 security/security.c       | 1 -
 security/yama/yama_lsm.c  | 7 ++++++-
 4 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 9df08955f684..5be95c6155b4 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2092,10 +2092,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 e20c2a3143e7..e37de9a44747 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 cb25f321e044..c4ba5832ef2f 100644
--- a/security/security.c
+++ b/security/security.c
@@ -304,7 +304,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..f2b1f47f98e8 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -477,9 +477,14 @@ 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)
+	.init = yama_init,
+END_LSM;
-- 
2.17.1

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

* [PATCH security-next v3 25/29] Yama: Initialize as ordered LSM
  2018-09-25  0:18 ` [PATCH security-next v3 25/29] Yama: " Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 include/linux/lsm_hooks.h | 5 -----
 security/Kconfig          | 2 +-
 security/security.c       | 1 -
 security/yama/yama_lsm.c  | 7 ++++++-
 4 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 9df08955f684..5be95c6155b4 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2092,10 +2092,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 e20c2a3143e7..e37de9a44747 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 cb25f321e044..c4ba5832ef2f 100644
--- a/security/security.c
+++ b/security/security.c
@@ -304,7 +304,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..f2b1f47f98e8 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -477,9 +477,14 @@ 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)
+	.init = yama_init,
+END_LSM;
-- 
2.17.1

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

* [PATCH security-next v3 26/29] LSM: Introduce enum lsm_order
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (25 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 25/29] Yama: " Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 27/29] capability: Initialize as LSM_ORDER_FIRST Kees Cook
                   ` (3 subsequent siblings)
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 5be95c6155b4..b38902ea0be5 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;	/* Populated automatically. */
+	enum lsm_order order;	/* Optional: default is LSM_ORDER_MUTABLE */
 	unsigned long flags;	/* Optional: flags describing LSM */
 	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
 	int (*init)(void);
diff --git a/security/security.c b/security/security.c
index c4ba5832ef2f..8b93afa75e3c 100644
--- a/security/security.c
+++ b/security/security.c
@@ -148,7 +148,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;
@@ -166,6 +167,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");
 
@@ -174,9 +181,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] 164+ messages in thread

* [PATCH security-next v3 26/29] LSM: Introduce enum lsm_order
  2018-09-25  0:18 ` [PATCH security-next v3 26/29] LSM: Introduce enum lsm_order Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 5be95c6155b4..b38902ea0be5 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;	/* Populated automatically. */
+	enum lsm_order order;	/* Optional: default is LSM_ORDER_MUTABLE */
 	unsigned long flags;	/* Optional: flags describing LSM */
 	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
 	int (*init)(void);
diff --git a/security/security.c b/security/security.c
index c4ba5832ef2f..8b93afa75e3c 100644
--- a/security/security.c
+++ b/security/security.c
@@ -148,7 +148,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;
@@ -166,6 +167,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");
 
@@ -174,9 +181,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] 164+ messages in thread

* [PATCH security-next v3 27/29] capability: Initialize as LSM_ORDER_FIRST
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (26 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 26/29] LSM: Introduce enum lsm_order Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 28/29] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
                   ` (2 subsequent siblings)
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 include/linux/lsm_hooks.h | 2 --
 security/commoncap.c      | 8 +++++++-
 security/security.c       | 9 ++++-----
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index b38902ea0be5..950042fb2385 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2098,6 +2098,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..7a6abaec65de 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1366,10 +1366,16 @@ 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)
+	.order = LSM_ORDER_FIRST,
+	.init = capability_init,
+END_LSM;
+
 #endif /* CONFIG_SECURITY */
diff --git a/security/security.c b/security/security.c
index 8b93afa75e3c..ade74b90b73c 100644
--- a/security/security.c
+++ b/security/security.c
@@ -62,6 +62,10 @@ static bool debug __initdata;
 
 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;
 
@@ -314,11 +318,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] 164+ messages in thread

* [PATCH security-next v3 27/29] capability: Initialize as LSM_ORDER_FIRST
  2018-09-25  0:18 ` [PATCH security-next v3 27/29] capability: Initialize as LSM_ORDER_FIRST Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 include/linux/lsm_hooks.h | 2 --
 security/commoncap.c      | 8 +++++++-
 security/security.c       | 9 ++++-----
 3 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index b38902ea0be5..950042fb2385 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2098,6 +2098,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..7a6abaec65de 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1366,10 +1366,16 @@ 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)
+	.order = LSM_ORDER_FIRST,
+	.init = capability_init,
+END_LSM;
+
 #endif /* CONFIG_SECURITY */
diff --git a/security/security.c b/security/security.c
index 8b93afa75e3c..ade74b90b73c 100644
--- a/security/security.c
+++ b/security/security.c
@@ -62,6 +62,10 @@ static bool debug __initdata;
 
 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;
 
@@ -314,11 +318,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] 164+ messages in thread

* [PATCH security-next v3 28/29] LSM: Separate idea of "major" LSM from "exclusive" LSM
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (27 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 27/29] capability: Initialize as LSM_ORDER_FIRST Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-25  0:18 ` [PATCH security-next v3 29/29] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
  2018-09-28 15:55 ` [PATCH security-next v3 00/29] LSM: Explict LSM ordering Casey Schaufler
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 950042fb2385..0f5d44d0a9cc 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 5399c2f03536..d68bc931d388 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1601,7 +1601,7 @@ static int __init apparmor_init(void)
 }
 
 DEFINE_LSM(apparmor)
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &apparmor_enabled,
 	.init = apparmor_init,
 END_LSM;
diff --git a/security/security.c b/security/security.c
index ade74b90b73c..5a3e19f1fe48 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 bool debug __initdata;
 #define init_debug(...)						\
@@ -204,6 +205,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;
 }
 
@@ -219,6 +226,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 409a9252aeb6..5461d54fcd99 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7193,7 +7193,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)
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &selinux_enabled,
 	.init = selinux_init,
 END_LSM;
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index e79fad43a8e3..e46c1ea8cf84 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4880,6 +4880,6 @@ static __init int smack_init(void)
  * all processes and objects when they are created.
  */
 DEFINE_LSM(smack)
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = smack_init,
 END_LSM;
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 39bb994ebe09..cc39eb8df61a 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -549,6 +549,6 @@ static int __init tomoyo_init(void)
 }
 
 DEFINE_LSM(tomoyo)
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = tomoyo_init,
 END_LSM;
-- 
2.17.1

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

* [PATCH security-next v3 28/29] LSM: Separate idea of "major" LSM from "exclusive" LSM
  2018-09-25  0:18 ` [PATCH security-next v3 28/29] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 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 950042fb2385..0f5d44d0a9cc 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 5399c2f03536..d68bc931d388 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1601,7 +1601,7 @@ static int __init apparmor_init(void)
 }
 
 DEFINE_LSM(apparmor)
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &apparmor_enabled,
 	.init = apparmor_init,
 END_LSM;
diff --git a/security/security.c b/security/security.c
index ade74b90b73c..5a3e19f1fe48 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 bool debug __initdata;
 #define init_debug(...)						\
@@ -204,6 +205,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;
 }
 
@@ -219,6 +226,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 409a9252aeb6..5461d54fcd99 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7193,7 +7193,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)
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &selinux_enabled,
 	.init = selinux_init,
 END_LSM;
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index e79fad43a8e3..e46c1ea8cf84 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4880,6 +4880,6 @@ static __init int smack_init(void)
  * all processes and objects when they are created.
  */
 DEFINE_LSM(smack)
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = smack_init,
 END_LSM;
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 39bb994ebe09..cc39eb8df61a 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -549,6 +549,6 @@ static int __init tomoyo_init(void)
 }
 
 DEFINE_LSM(tomoyo)
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = tomoyo_init,
 END_LSM;
-- 
2.17.1

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

* [PATCH security-next v3 29/29] LSM: Add all exclusive LSMs to ordered initialization
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (28 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 28/29] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
@ 2018-09-25  0:18 ` Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-28 15:55 ` [PATCH security-next v3 00/29] LSM: Explict LSM ordering Casey Schaufler
  30 siblings, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/Kconfig    | 43 ++++---------------------------------------
 security/security.c | 23 +----------------------
 2 files changed, 5 insertions(+), 61 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index e37de9a44747..efa4826c3d99 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 5a3e19f1fe48..fedc26fb8554 100644
--- a/security/security.c
+++ b/security/security.c
@@ -154,7 +154,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;
@@ -186,8 +185,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");
 	}
 
@@ -245,18 +243,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,
 				    void (*set)(struct lsm_info *, bool),
 				    bool enabled)
@@ -290,8 +276,6 @@ static void __init prepare_lsm_enable(void)
 	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;
 
@@ -334,11 +318,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] 164+ messages in thread

* [PATCH security-next v3 29/29] LSM: Add all exclusive LSMs to ordered initialization
  2018-09-25  0:18 ` [PATCH security-next v3 29/29] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
@ 2018-09-25  0:18   ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-25  0:18 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>
---
 security/Kconfig    | 43 ++++---------------------------------------
 security/security.c | 23 +----------------------
 2 files changed, 5 insertions(+), 61 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index e37de9a44747..efa4826c3d99 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 5a3e19f1fe48..fedc26fb8554 100644
--- a/security/security.c
+++ b/security/security.c
@@ -154,7 +154,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;
@@ -186,8 +185,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");
 	}
 
@@ -245,18 +243,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,
 				    void (*set)(struct lsm_info *, bool),
 				    bool enabled)
@@ -290,8 +276,6 @@ static void __init prepare_lsm_enable(void)
 	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;
 
@@ -334,11 +318,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] 164+ messages in thread

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-25  0:18 ` [PATCH security-next v3 04/29] LSM: Remove initcall tracing Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-09-26 16:35   ` Steven Rostedt
  2018-09-26 16:35     ` Steven Rostedt
  2018-09-26 18:35     ` Kees Cook
  2018-10-01 21:07   ` John Johansen
  2 siblings, 2 replies; 164+ messages in thread
From: Steven Rostedt @ 2018-09-26 16:35 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

On Mon, 24 Sep 2018 17:18:07 -0700
Kees Cook <keescook@chromium.org> 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.

I'm not against the change, but how much are they going to "no longer
resemble regular init calls"?

-- Steve

> 
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  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++;
>  	}
>  }

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-26 16:35   ` Steven Rostedt
@ 2018-09-26 16:35     ` Steven Rostedt
  2018-09-26 18:35     ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: Steven Rostedt @ 2018-09-26 16:35 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, linux-doc, linux-arch, linux-kernel

On Mon, 24 Sep 2018 17:18:07 -0700
Kees Cook <keescook@chromium.org> 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.

I'm not against the change, but how much are they going to "no longer
resemble regular init calls"?

-- Steve

> 
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  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++;
>  	}
>  }

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-26 16:35   ` Steven Rostedt
  2018-09-26 16:35     ` Steven Rostedt
@ 2018-09-26 18:35     ` Kees Cook
  2018-09-26 18:35       ` Kees Cook
  2018-09-30 23:25       ` Steven Rostedt
  1 sibling, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-26 18:35 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 24 Sep 2018 17:18:07 -0700
> Kees Cook <keescook@chromium.org> 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.
>
> I'm not against the change, but how much are they going to "no longer
> resemble regular init calls"?

My take on "regular" init calls is that they're always run, link-time
ordered, etc. The changes proposed here will make it so not all
initialization are run depending on runtime configurations, ordering
will be flexible, etc.

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-26 18:35     ` Kees Cook
@ 2018-09-26 18:35       ` Kees Cook
  2018-09-30 23:25       ` Steven Rostedt
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-26 18:35 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 24 Sep 2018 17:18:07 -0700
> Kees Cook <keescook@chromium.org> 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.
>
> I'm not against the change, but how much are they going to "no longer
> resemble regular init calls"?

My take on "regular" init calls is that they're always run, link-time
ordered, etc. The changes proposed here will make it so not all
initialization are run depending on runtime configurations, ordering
will be flexible, etc.

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
                   ` (29 preceding siblings ...)
  2018-09-25  0:18 ` [PATCH security-next v3 29/29] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
@ 2018-09-28 15:55 ` Casey Schaufler
  2018-09-28 15:55   ` Casey Schaufler
  2018-09-28 20:01   ` Kees Cook
  30 siblings, 2 replies; 164+ messages in thread
From: Casey Schaufler @ 2018-09-28 15:55 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: John Johansen, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 9/24/2018 5:18 PM, Kees Cook wrote:
> v3:
> - add CONFIG_LSM_ENABLE and refactor resulting logic

Kees, you can add my

	Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>

for this entire patch set. Thank you for taking this on, it's
a significant and important chunk of the LSM infrastructure
update.


> ...
> 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
>
> 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         |  20 +
>  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                     |  43 ++-
>  include/linux/module.h                        |   1 -
>  security/Kconfig                              |  61 ++-
>  security/apparmor/lsm.c                       |  16 +-
>  security/commoncap.c                          |   8 +-
>  security/integrity/iint.c                     |   5 +-
>  security/loadpin/Kconfig                      |   4 +-
>  security/loadpin/loadpin.c                    |  28 +-
>  security/security.c                           | 351 +++++++++++++++---
>  security/selinux/hooks.c                      |  16 +-
>  security/smack/smack_lsm.c                    |   8 +-
>  security/tomoyo/tomoyo.c                      |   7 +-
>  security/yama/yama_lsm.c                      |   7 +-
>  24 files changed, 438 insertions(+), 175 deletions(-)
>

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 15:55 ` [PATCH security-next v3 00/29] LSM: Explict LSM ordering Casey Schaufler
@ 2018-09-28 15:55   ` Casey Schaufler
  2018-09-28 20:01   ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: Casey Schaufler @ 2018-09-28 15:55 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: John Johansen, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 9/24/2018 5:18 PM, Kees Cook wrote:
> v3:
> - add CONFIG_LSM_ENABLE and refactor resulting logic

Kees, you can add my

	Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>

for this entire patch set. Thank you for taking this on, it's
a significant and important chunk of the LSM infrastructure
update.


> ...
> 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
>
> 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         |  20 +
>  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                     |  43 ++-
>  include/linux/module.h                        |   1 -
>  security/Kconfig                              |  61 ++-
>  security/apparmor/lsm.c                       |  16 +-
>  security/commoncap.c                          |   8 +-
>  security/integrity/iint.c                     |   5 +-
>  security/loadpin/Kconfig                      |   4 +-
>  security/loadpin/loadpin.c                    |  28 +-
>  security/security.c                           | 351 +++++++++++++++---
>  security/selinux/hooks.c                      |  16 +-
>  security/smack/smack_lsm.c                    |   8 +-
>  security/tomoyo/tomoyo.c                      |   7 +-
>  security/yama/yama_lsm.c                      |   7 +-
>  24 files changed, 438 insertions(+), 175 deletions(-)
>

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 15:55 ` [PATCH security-next v3 00/29] LSM: Explict LSM ordering Casey Schaufler
  2018-09-28 15:55   ` Casey Schaufler
@ 2018-09-28 20:01   ` Kees Cook
  2018-09-28 20:01     ` Kees Cook
                       ` (2 more replies)
  1 sibling, 3 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-28 20:01 UTC (permalink / raw)
  To: Casey Schaufler
  Cc: James Morris, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/24/2018 5:18 PM, Kees Cook wrote:
>> v3:
>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>
> Kees, you can add my
>
>         Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>
> for this entire patch set. Thank you for taking this on, it's
> a significant and important chunk of the LSM infrastructure
> update.

Thanks!

John, you'd looked at this a bit too -- do the results line up with
your expectations?

Any thoughts from SELinux, TOMOYO, or IMA folks?

-Kees

>
>
>> ...
>> 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
>>
>> 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         |  20 +
>>  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                     |  43 ++-
>>  include/linux/module.h                        |   1 -
>>  security/Kconfig                              |  61 ++-
>>  security/apparmor/lsm.c                       |  16 +-
>>  security/commoncap.c                          |   8 +-
>>  security/integrity/iint.c                     |   5 +-
>>  security/loadpin/Kconfig                      |   4 +-
>>  security/loadpin/loadpin.c                    |  28 +-
>>  security/security.c                           | 351 +++++++++++++++---
>>  security/selinux/hooks.c                      |  16 +-
>>  security/smack/smack_lsm.c                    |   8 +-
>>  security/tomoyo/tomoyo.c                      |   7 +-
>>  security/yama/yama_lsm.c                      |   7 +-
>>  24 files changed, 438 insertions(+), 175 deletions(-)
>>
>



-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 20:01   ` Kees Cook
@ 2018-09-28 20:01     ` Kees Cook
  2018-09-28 20:25     ` Stephen Smalley
  2018-09-29 10:48     ` Tetsuo Handa
  2 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-28 20:01 UTC (permalink / raw)
  To: Casey Schaufler
  Cc: James Morris, John Johansen, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 9/24/2018 5:18 PM, Kees Cook wrote:
>> v3:
>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>
> Kees, you can add my
>
>         Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>
> for this entire patch set. Thank you for taking this on, it's
> a significant and important chunk of the LSM infrastructure
> update.

Thanks!

John, you'd looked at this a bit too -- do the results line up with
your expectations?

Any thoughts from SELinux, TOMOYO, or IMA folks?

-Kees

>
>
>> ...
>> 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
>>
>> 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         |  20 +
>>  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                     |  43 ++-
>>  include/linux/module.h                        |   1 -
>>  security/Kconfig                              |  61 ++-
>>  security/apparmor/lsm.c                       |  16 +-
>>  security/commoncap.c                          |   8 +-
>>  security/integrity/iint.c                     |   5 +-
>>  security/loadpin/Kconfig                      |   4 +-
>>  security/loadpin/loadpin.c                    |  28 +-
>>  security/security.c                           | 351 +++++++++++++++---
>>  security/selinux/hooks.c                      |  16 +-
>>  security/smack/smack_lsm.c                    |   8 +-
>>  security/tomoyo/tomoyo.c                      |   7 +-
>>  security/yama/yama_lsm.c                      |   7 +-
>>  24 files changed, 438 insertions(+), 175 deletions(-)
>>
>



-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 20:01   ` Kees Cook
  2018-09-28 20:01     ` Kees Cook
@ 2018-09-28 20:25     ` Stephen Smalley
  2018-09-28 20:25       ` Stephen Smalley
  2018-09-28 20:33       ` Stephen Smalley
  2018-09-29 10:48     ` Tetsuo Handa
  2 siblings, 2 replies; 164+ messages in thread
From: Stephen Smalley @ 2018-09-28 20:25 UTC (permalink / raw)
  To: Kees Cook, Casey Schaufler
  Cc: James Morris, John Johansen, Tetsuo Handa, Paul Moore, Schaufler,
	Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION, linux-arch,
	LKML

On 09/28/2018 04:01 PM, Kees Cook wrote:
> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>> v3:
>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>
>> Kees, you can add my
>>
>>          Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>
>> for this entire patch set. Thank you for taking this on, it's
>> a significant and important chunk of the LSM infrastructure
>> update.
> 
> Thanks!
> 
> John, you'd looked at this a bit too -- do the results line up with
> your expectations?
> 
> Any thoughts from SELinux, TOMOYO, or IMA folks?

What's it relative to?  First patch fails for me on current security/next.

Is there a branch in your repo that has the v3 patches?

> 
> -Kees
> 
>>
>>
>>> ...
>>> 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
>>>
>>> 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         |  20 +
>>>   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                     |  43 ++-
>>>   include/linux/module.h                        |   1 -
>>>   security/Kconfig                              |  61 ++-
>>>   security/apparmor/lsm.c                       |  16 +-
>>>   security/commoncap.c                          |   8 +-
>>>   security/integrity/iint.c                     |   5 +-
>>>   security/loadpin/Kconfig                      |   4 +-
>>>   security/loadpin/loadpin.c                    |  28 +-
>>>   security/security.c                           | 351 +++++++++++++++---
>>>   security/selinux/hooks.c                      |  16 +-
>>>   security/smack/smack_lsm.c                    |   8 +-
>>>   security/tomoyo/tomoyo.c                      |   7 +-
>>>   security/yama/yama_lsm.c                      |   7 +-
>>>   24 files changed, 438 insertions(+), 175 deletions(-)
>>>
>>
> 
> 
> 

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 20:25     ` Stephen Smalley
@ 2018-09-28 20:25       ` Stephen Smalley
  2018-09-28 20:33       ` Stephen Smalley
  1 sibling, 0 replies; 164+ messages in thread
From: Stephen Smalley @ 2018-09-28 20:25 UTC (permalink / raw)
  To: Kees Cook, Casey Schaufler
  Cc: James Morris, John Johansen, Tetsuo Handa, Paul Moore, Schaufler,
	Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION, linux-arch,
	LKML

On 09/28/2018 04:01 PM, Kees Cook wrote:
> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>> v3:
>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>
>> Kees, you can add my
>>
>>          Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>
>> for this entire patch set. Thank you for taking this on, it's
>> a significant and important chunk of the LSM infrastructure
>> update.
> 
> Thanks!
> 
> John, you'd looked at this a bit too -- do the results line up with
> your expectations?
> 
> Any thoughts from SELinux, TOMOYO, or IMA folks?

What's it relative to?  First patch fails for me on current security/next.

Is there a branch in your repo that has the v3 patches?

> 
> -Kees
> 
>>
>>
>>> ...
>>> 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
>>>
>>> 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         |  20 +
>>>   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                     |  43 ++-
>>>   include/linux/module.h                        |   1 -
>>>   security/Kconfig                              |  61 ++-
>>>   security/apparmor/lsm.c                       |  16 +-
>>>   security/commoncap.c                          |   8 +-
>>>   security/integrity/iint.c                     |   5 +-
>>>   security/loadpin/Kconfig                      |   4 +-
>>>   security/loadpin/loadpin.c                    |  28 +-
>>>   security/security.c                           | 351 +++++++++++++++---
>>>   security/selinux/hooks.c                      |  16 +-
>>>   security/smack/smack_lsm.c                    |   8 +-
>>>   security/tomoyo/tomoyo.c                      |   7 +-
>>>   security/yama/yama_lsm.c                      |   7 +-
>>>   24 files changed, 438 insertions(+), 175 deletions(-)
>>>
>>
> 
> 
> 

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 20:25     ` Stephen Smalley
  2018-09-28 20:25       ` Stephen Smalley
@ 2018-09-28 20:33       ` Stephen Smalley
  2018-09-28 20:33         ` Stephen Smalley
  2018-09-28 20:54         ` Kees Cook
  1 sibling, 2 replies; 164+ messages in thread
From: Stephen Smalley @ 2018-09-28 20:33 UTC (permalink / raw)
  To: Kees Cook, Casey Schaufler
  Cc: James Morris, John Johansen, Tetsuo Handa, Paul Moore, Schaufler,
	Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION, linux-arch,
	LKML

On 09/28/2018 04:25 PM, Stephen Smalley wrote:
> On 09/28/2018 04:01 PM, Kees Cook wrote:
>> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler 
>> <casey@schaufler-ca.com> wrote:
>>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>>> v3:
>>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>>
>>> Kees, you can add my
>>>
>>>          Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>>
>>> for this entire patch set. Thank you for taking this on, it's
>>> a significant and important chunk of the LSM infrastructure
>>> update.
>>
>> Thanks!
>>
>> John, you'd looked at this a bit too -- do the results line up with
>> your expectations?
>>
>> Any thoughts from SELinux, TOMOYO, or IMA folks?
> 
> What's it relative to?  First patch fails for me on current security/next.

Never mind - user error ;)

> Is there a branch in your repo that has the v3 patches?

But still wondered about this one.

> 
>>
>> -Kees
>>
>>>
>>>
>>>> ...
>>>> 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
>>>>
>>>> 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         |  20 +
>>>>   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                     |  43 ++-
>>>>   include/linux/module.h                        |   1 -
>>>>   security/Kconfig                              |  61 ++-
>>>>   security/apparmor/lsm.c                       |  16 +-
>>>>   security/commoncap.c                          |   8 +-
>>>>   security/integrity/iint.c                     |   5 +-
>>>>   security/loadpin/Kconfig                      |   4 +-
>>>>   security/loadpin/loadpin.c                    |  28 +-
>>>>   security/security.c                           | 351 
>>>> +++++++++++++++---
>>>>   security/selinux/hooks.c                      |  16 +-
>>>>   security/smack/smack_lsm.c                    |   8 +-
>>>>   security/tomoyo/tomoyo.c                      |   7 +-
>>>>   security/yama/yama_lsm.c                      |   7 +-
>>>>   24 files changed, 438 insertions(+), 175 deletions(-)
>>>>
>>>
>>
>>
>>
> 

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 20:33       ` Stephen Smalley
@ 2018-09-28 20:33         ` Stephen Smalley
  2018-09-28 20:54         ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: Stephen Smalley @ 2018-09-28 20:33 UTC (permalink / raw)
  To: Kees Cook, Casey Schaufler
  Cc: James Morris, John Johansen, Tetsuo Handa, Paul Moore, Schaufler,
	Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION, linux-arch,
	LKML

On 09/28/2018 04:25 PM, Stephen Smalley wrote:
> On 09/28/2018 04:01 PM, Kees Cook wrote:
>> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler 
>> <casey@schaufler-ca.com> wrote:
>>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>>> v3:
>>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>>
>>> Kees, you can add my
>>>
>>>          Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>>
>>> for this entire patch set. Thank you for taking this on, it's
>>> a significant and important chunk of the LSM infrastructure
>>> update.
>>
>> Thanks!
>>
>> John, you'd looked at this a bit too -- do the results line up with
>> your expectations?
>>
>> Any thoughts from SELinux, TOMOYO, or IMA folks?
> 
> What's it relative to?  First patch fails for me on current security/next.

Never mind - user error ;)

> Is there a branch in your repo that has the v3 patches?

But still wondered about this one.

> 
>>
>> -Kees
>>
>>>
>>>
>>>> ...
>>>> 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
>>>>
>>>> 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         |  20 +
>>>>   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                     |  43 ++-
>>>>   include/linux/module.h                        |   1 -
>>>>   security/Kconfig                              |  61 ++-
>>>>   security/apparmor/lsm.c                       |  16 +-
>>>>   security/commoncap.c                          |   8 +-
>>>>   security/integrity/iint.c                     |   5 +-
>>>>   security/loadpin/Kconfig                      |   4 +-
>>>>   security/loadpin/loadpin.c                    |  28 +-
>>>>   security/security.c                           | 351 
>>>> +++++++++++++++---
>>>>   security/selinux/hooks.c                      |  16 +-
>>>>   security/smack/smack_lsm.c                    |   8 +-
>>>>   security/tomoyo/tomoyo.c                      |   7 +-
>>>>   security/yama/yama_lsm.c                      |   7 +-
>>>>   24 files changed, 438 insertions(+), 175 deletions(-)
>>>>
>>>
>>
>>
>>
> 

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 20:33       ` Stephen Smalley
  2018-09-28 20:33         ` Stephen Smalley
@ 2018-09-28 20:54         ` Kees Cook
  2018-09-28 20:54           ` Kees Cook
  1 sibling, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-28 20:54 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Casey Schaufler, James Morris, John Johansen, Tetsuo Handa,
	Paul Moore, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Fri, Sep 28, 2018 at 1:33 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/28/2018 04:25 PM, Stephen Smalley wrote:
>>
>> On 09/28/2018 04:01 PM, Kees Cook wrote:
>>>
>>> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com>
>>> wrote:
>>>>
>>>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>>>>
>>>>> v3:
>>>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>>>
>>>>
>>>> Kees, you can add my
>>>>
>>>>          Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>>>
>>>> for this entire patch set. Thank you for taking this on, it's
>>>> a significant and important chunk of the LSM infrastructure
>>>> update.
>>>
>>>
>>> Thanks!
>>>
>>> John, you'd looked at this a bit too -- do the results line up with
>>> your expectations?
>>>
>>> Any thoughts from SELinux, TOMOYO, or IMA folks?
>>
>>
>> What's it relative to?  First patch fails for me on current security/next.
>
> Never mind - user error ;)

FWIW, it's against v4.19-rc2.

>> Is there a branch in your repo that has the v3 patches?
>
> But still wondered about this one.

Oops! Sorry, I didn't push to kernel.org. Now pushed!

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v3

(and "preview" v4 also with Reviewed-bys added and a cosmetic fix.)

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 20:54         ` Kees Cook
@ 2018-09-28 20:54           ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-28 20:54 UTC (permalink / raw)
  To: Stephen Smalley
  Cc: Casey Schaufler, James Morris, John Johansen, Tetsuo Handa,
	Paul Moore, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Fri, Sep 28, 2018 at 1:33 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On 09/28/2018 04:25 PM, Stephen Smalley wrote:
>>
>> On 09/28/2018 04:01 PM, Kees Cook wrote:
>>>
>>> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com>
>>> wrote:
>>>>
>>>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>>>>
>>>>> v3:
>>>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>>>
>>>>
>>>> Kees, you can add my
>>>>
>>>>          Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>>>
>>>> for this entire patch set. Thank you for taking this on, it's
>>>> a significant and important chunk of the LSM infrastructure
>>>> update.
>>>
>>>
>>> Thanks!
>>>
>>> John, you'd looked at this a bit too -- do the results line up with
>>> your expectations?
>>>
>>> Any thoughts from SELinux, TOMOYO, or IMA folks?
>>
>>
>> What's it relative to?  First patch fails for me on current security/next.
>
> Never mind - user error ;)

FWIW, it's against v4.19-rc2.

>> Is there a branch in your repo that has the v3 patches?
>
> But still wondered about this one.

Oops! Sorry, I didn't push to kernel.org. Now pushed!

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v3

(and "preview" v4 also with Reviewed-bys added and a cosmetic fix.)

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-28 20:01   ` Kees Cook
  2018-09-28 20:01     ` Kees Cook
  2018-09-28 20:25     ` Stephen Smalley
@ 2018-09-29 10:48     ` Tetsuo Handa
  2018-09-29 10:48       ` Tetsuo Handa
                         ` (2 more replies)
  2 siblings, 3 replies; 164+ messages in thread
From: Tetsuo Handa @ 2018-09-29 10:48 UTC (permalink / raw)
  To: Kees Cook, Casey Schaufler
  Cc: James Morris, John Johansen, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 2018/09/29 5:01, Kees Cook wrote:
> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>> v3:
>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>
>> Kees, you can add my
>>
>>         Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>
>> for this entire patch set. Thank you for taking this on, it's
>> a significant and important chunk of the LSM infrastructure
>> update.
> 
> Thanks!
> 
> John, you'd looked at this a bit too -- do the results line up with
> your expectations?
> 
> Any thoughts from SELinux, TOMOYO, or IMA folks?

I'm OK with this approach. Thank you.



Just wondering what is "__lsm_name_##lsm" for...

+#define DEFINE_LSM(lsm)                                                        \
+       static const char __lsm_name_##lsm[] __initconst                \
+               __aligned(1) = #lsm;                                    \
+       static struct lsm_info __lsm_##lsm                              \
+               __used __section(.lsm_info.init)                        \
+               __aligned(sizeof(unsigned long))                        \
+               = {                                                     \
+                       .name = __lsm_name_##lsm,                       \
+
+#define END_LSM          }

We could do something like below so that funny END_LSM is not required?
I felt } like a typo error at the first glance. What we need is to
gather into one section with appropriate alignment, isn't it?

#define LSM_INFO                                                        \
	static struct lsm_info __lsm_                                   \
		__used __section(.lsm_info.init)                        \
		__aligned(sizeof(unsigned long))                        \

LSM_INFO = {
	.name = "tomoyo",
	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
	.init = tomoyo_init,
};

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-29 10:48     ` Tetsuo Handa
@ 2018-09-29 10:48       ` Tetsuo Handa
  2018-09-29 18:18       ` Kees Cook
  2018-09-29 18:19       ` John Johansen
  2 siblings, 0 replies; 164+ messages in thread
From: Tetsuo Handa @ 2018-09-29 10:48 UTC (permalink / raw)
  To: Kees Cook, Casey Schaufler
  Cc: James Morris, John Johansen, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 2018/09/29 5:01, Kees Cook wrote:
> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>> v3:
>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>
>> Kees, you can add my
>>
>>         Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>
>> for this entire patch set. Thank you for taking this on, it's
>> a significant and important chunk of the LSM infrastructure
>> update.
> 
> Thanks!
> 
> John, you'd looked at this a bit too -- do the results line up with
> your expectations?
> 
> Any thoughts from SELinux, TOMOYO, or IMA folks?

I'm OK with this approach. Thank you.



Just wondering what is "__lsm_name_##lsm" for...

+#define DEFINE_LSM(lsm)                                                        \
+       static const char __lsm_name_##lsm[] __initconst                \
+               __aligned(1) = #lsm;                                    \
+       static struct lsm_info __lsm_##lsm                              \
+               __used __section(.lsm_info.init)                        \
+               __aligned(sizeof(unsigned long))                        \
+               = {                                                     \
+                       .name = __lsm_name_##lsm,                       \
+
+#define END_LSM          }

We could do something like below so that funny END_LSM is not required?
I felt } like a typo error at the first glance. What we need is to
gather into one section with appropriate alignment, isn't it?

#define LSM_INFO                                                        \
	static struct lsm_info __lsm_                                   \
		__used __section(.lsm_info.init)                        \
		__aligned(sizeof(unsigned long))                        \

LSM_INFO = {
	.name = "tomoyo",
	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
	.init = tomoyo_init,
};

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-29 10:48     ` Tetsuo Handa
  2018-09-29 10:48       ` Tetsuo Handa
@ 2018-09-29 18:18       ` Kees Cook
  2018-09-29 18:18         ` Kees Cook
  2018-09-30  2:36         ` Tetsuo Handa
  2018-09-29 18:19       ` John Johansen
  2 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-29 18:18 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Casey Schaufler, James Morris, John Johansen, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Sat, Sep 29, 2018 at 3:48 AM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2018/09/29 5:01, Kees Cook wrote:
>> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>>> v3:
>>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>>
>>> Kees, you can add my
>>>
>>>         Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>>
>>> for this entire patch set. Thank you for taking this on, it's
>>> a significant and important chunk of the LSM infrastructure
>>> update.
>>
>> Thanks!
>>
>> John, you'd looked at this a bit too -- do the results line up with
>> your expectations?
>>
>> Any thoughts from SELinux, TOMOYO, or IMA folks?
>
> I'm OK with this approach. Thank you.

Thanks for looking it over!

> Just wondering what is "__lsm_name_##lsm" for...
>
> +#define DEFINE_LSM(lsm)                                                        \
> +       static const char __lsm_name_##lsm[] __initconst                \
> +               __aligned(1) = #lsm;                                    \
> +       static struct lsm_info __lsm_##lsm                              \
> +               __used __section(.lsm_info.init)                        \
> +               __aligned(sizeof(unsigned long))                        \
> +               = {                                                     \
> +                       .name = __lsm_name_##lsm,                       \
> +
> +#define END_LSM          }

I wasn't super happy with the END_LSM thing, but I wanted to be able
to declare the name as __initconst, otherwise it needlessly stays in
memory after init. That said, it's not a huge deal, and maybe
readability trumps a tiny meory savings?

> We could do something like below so that funny END_LSM is not required?
> I felt } like a typo error at the first glance. What we need is to
> gather into one section with appropriate alignment, isn't it?
>
> #define LSM_INFO                                                        \
>         static struct lsm_info __lsm_                                   \
>                 __used __section(.lsm_info.init)                        \
>                 __aligned(sizeof(unsigned long))                        \
>
> LSM_INFO = {
>         .name = "tomoyo",
>         .flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
>         .init = tomoyo_init,
> };

I thought the structure instances would need a unique name, but it
seems the section naming removes that requirement. This seems only to
be needed if we had multiple LSMs defined in the same source file.
Though I wonder if this would be a problem for LTO in the future?

I'm happy to do whatever.

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-29 18:18       ` Kees Cook
@ 2018-09-29 18:18         ` Kees Cook
  2018-09-30  2:36         ` Tetsuo Handa
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-29 18:18 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Casey Schaufler, James Morris, John Johansen, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Sat, Sep 29, 2018 at 3:48 AM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2018/09/29 5:01, Kees Cook wrote:
>> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>>> v3:
>>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>>
>>> Kees, you can add my
>>>
>>>         Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>>
>>> for this entire patch set. Thank you for taking this on, it's
>>> a significant and important chunk of the LSM infrastructure
>>> update.
>>
>> Thanks!
>>
>> John, you'd looked at this a bit too -- do the results line up with
>> your expectations?
>>
>> Any thoughts from SELinux, TOMOYO, or IMA folks?
>
> I'm OK with this approach. Thank you.

Thanks for looking it over!

> Just wondering what is "__lsm_name_##lsm" for...
>
> +#define DEFINE_LSM(lsm)                                                        \
> +       static const char __lsm_name_##lsm[] __initconst                \
> +               __aligned(1) = #lsm;                                    \
> +       static struct lsm_info __lsm_##lsm                              \
> +               __used __section(.lsm_info.init)                        \
> +               __aligned(sizeof(unsigned long))                        \
> +               = {                                                     \
> +                       .name = __lsm_name_##lsm,                       \
> +
> +#define END_LSM          }

I wasn't super happy with the END_LSM thing, but I wanted to be able
to declare the name as __initconst, otherwise it needlessly stays in
memory after init. That said, it's not a huge deal, and maybe
readability trumps a tiny meory savings?

> We could do something like below so that funny END_LSM is not required?
> I felt } like a typo error at the first glance. What we need is to
> gather into one section with appropriate alignment, isn't it?
>
> #define LSM_INFO                                                        \
>         static struct lsm_info __lsm_                                   \
>                 __used __section(.lsm_info.init)                        \
>                 __aligned(sizeof(unsigned long))                        \
>
> LSM_INFO = {
>         .name = "tomoyo",
>         .flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
>         .init = tomoyo_init,
> };

I thought the structure instances would need a unique name, but it
seems the section naming removes that requirement. This seems only to
be needed if we had multiple LSMs defined in the same source file.
Though I wonder if this would be a problem for LTO in the future?

I'm happy to do whatever.

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-29 10:48     ` Tetsuo Handa
  2018-09-29 10:48       ` Tetsuo Handa
  2018-09-29 18:18       ` Kees Cook
@ 2018-09-29 18:19       ` John Johansen
  2018-09-29 18:19         ` John Johansen
  2 siblings, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-09-29 18:19 UTC (permalink / raw)
  To: Tetsuo Handa, Kees Cook, Casey Schaufler
  Cc: James Morris, Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 09/29/2018 03:48 AM, Tetsuo Handa wrote:
> On 2018/09/29 5:01, Kees Cook wrote:
>> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>>> v3:
>>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>>
>>> Kees, you can add my
>>>
>>>         Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>>
>>> for this entire patch set. Thank you for taking this on, it's
>>> a significant and important chunk of the LSM infrastructure
>>> update.
>>
>> Thanks!
>>
>> John, you'd looked at this a bit too -- do the results line up with
>> your expectations?
>>
>> Any thoughts from SELinux, TOMOYO, or IMA folks?
> 
> I'm OK with this approach. Thank you.
> 
> 
> 
> Just wondering what is "__lsm_name_##lsm" for...
> 
> +#define DEFINE_LSM(lsm)                                                        \
> +       static const char __lsm_name_##lsm[] __initconst                \
> +               __aligned(1) = #lsm;                                    \
> +       static struct lsm_info __lsm_##lsm                              \
> +               __used __section(.lsm_info.init)                        \
> +               __aligned(sizeof(unsigned long))                        \
> +               = {                                                     \
> +                       .name = __lsm_name_##lsm,                       \
> +
> +#define END_LSM          }
> 
> We could do something like below so that funny END_LSM is not required?
> I felt } like a typo error at the first glance. What we need is to
> gather into one section with appropriate alignment, isn't it?
> 

well and Kees was trying to automagically set the name. This threw
me off too at first and I am still trying to figure out if I would
prefer something simpler, and more standard like below.

> #define LSM_INFO                                                        \
> 	static struct lsm_info __lsm_                                   \
> 		__used __section(.lsm_info.init)                        \
> 		__aligned(sizeof(unsigned long))                        \
> 
> LSM_INFO = {
> 	.name = "tomoyo",
> 	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
> 	.init = tomoyo_init,
> };
> 

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-29 18:19       ` John Johansen
@ 2018-09-29 18:19         ` John Johansen
  0 siblings, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-09-29 18:19 UTC (permalink / raw)
  To: Tetsuo Handa, Kees Cook, Casey Schaufler
  Cc: James Morris, Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On 09/29/2018 03:48 AM, Tetsuo Handa wrote:
> On 2018/09/29 5:01, Kees Cook wrote:
>> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 9/24/2018 5:18 PM, Kees Cook wrote:
>>>> v3:
>>>> - add CONFIG_LSM_ENABLE and refactor resulting logic
>>>
>>> Kees, you can add my
>>>
>>>         Reviewed-by:Casey Schaufler <casey@schaufler-ca.com>
>>>
>>> for this entire patch set. Thank you for taking this on, it's
>>> a significant and important chunk of the LSM infrastructure
>>> update.
>>
>> Thanks!
>>
>> John, you'd looked at this a bit too -- do the results line up with
>> your expectations?
>>
>> Any thoughts from SELinux, TOMOYO, or IMA folks?
> 
> I'm OK with this approach. Thank you.
> 
> 
> 
> Just wondering what is "__lsm_name_##lsm" for...
> 
> +#define DEFINE_LSM(lsm)                                                        \
> +       static const char __lsm_name_##lsm[] __initconst                \
> +               __aligned(1) = #lsm;                                    \
> +       static struct lsm_info __lsm_##lsm                              \
> +               __used __section(.lsm_info.init)                        \
> +               __aligned(sizeof(unsigned long))                        \
> +               = {                                                     \
> +                       .name = __lsm_name_##lsm,                       \
> +
> +#define END_LSM          }
> 
> We could do something like below so that funny END_LSM is not required?
> I felt } like a typo error at the first glance. What we need is to
> gather into one section with appropriate alignment, isn't it?
> 

well and Kees was trying to automagically set the name. This threw
me off too at first and I am still trying to figure out if I would
prefer something simpler, and more standard like below.

> #define LSM_INFO                                                        \
> 	static struct lsm_info __lsm_                                   \
> 		__used __section(.lsm_info.init)                        \
> 		__aligned(sizeof(unsigned long))                        \
> 
> LSM_INFO = {
> 	.name = "tomoyo",
> 	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
> 	.init = tomoyo_init,
> };
> 

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-29 18:18       ` Kees Cook
  2018-09-29 18:18         ` Kees Cook
@ 2018-09-30  2:36         ` Tetsuo Handa
  2018-09-30  2:36           ` Tetsuo Handa
  2018-09-30 16:57           ` Kees Cook
  1 sibling, 2 replies; 164+ messages in thread
From: Tetsuo Handa @ 2018-09-30  2:36 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, James Morris, John Johansen, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On 2018/09/30 3:18, Kees Cook wrote:
>> Just wondering what is "__lsm_name_##lsm" for...
>>
>> +#define DEFINE_LSM(lsm)                                                        \
>> +       static const char __lsm_name_##lsm[] __initconst                \
>> +               __aligned(1) = #lsm;                                    \
>> +       static struct lsm_info __lsm_##lsm                              \
>> +               __used __section(.lsm_info.init)                        \
>> +               __aligned(sizeof(unsigned long))                        \
>> +               = {                                                     \
>> +                       .name = __lsm_name_##lsm,                       \
>> +
>> +#define END_LSM          }
> 
> I wasn't super happy with the END_LSM thing, but I wanted to be able
> to declare the name as __initconst, otherwise it needlessly stays in
> memory after init. That said, it's not a huge deal, and maybe
> readability trumps a tiny meory savings?

The value of .name field is a few bytes string, and is not sensitive
information. Keeping such string in non-__initdata section unlikely
increases total memory pages required for that module.

Unless we need to generate unique address of such string for some reason,
I think that this saving is pointless.

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-30  2:36         ` Tetsuo Handa
@ 2018-09-30  2:36           ` Tetsuo Handa
  2018-09-30 16:57           ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: Tetsuo Handa @ 2018-09-30  2:36 UTC (permalink / raw)
  To: Kees Cook
  Cc: Casey Schaufler, James Morris, John Johansen, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On 2018/09/30 3:18, Kees Cook wrote:
>> Just wondering what is "__lsm_name_##lsm" for...
>>
>> +#define DEFINE_LSM(lsm)                                                        \
>> +       static const char __lsm_name_##lsm[] __initconst                \
>> +               __aligned(1) = #lsm;                                    \
>> +       static struct lsm_info __lsm_##lsm                              \
>> +               __used __section(.lsm_info.init)                        \
>> +               __aligned(sizeof(unsigned long))                        \
>> +               = {                                                     \
>> +                       .name = __lsm_name_##lsm,                       \
>> +
>> +#define END_LSM          }
> 
> I wasn't super happy with the END_LSM thing, but I wanted to be able
> to declare the name as __initconst, otherwise it needlessly stays in
> memory after init. That said, it's not a huge deal, and maybe
> readability trumps a tiny meory savings?

The value of .name field is a few bytes string, and is not sensitive
information. Keeping such string in non-__initdata section unlikely
increases total memory pages required for that module.

Unless we need to generate unique address of such string for some reason,
I think that this saving is pointless.

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-30  2:36         ` Tetsuo Handa
  2018-09-30  2:36           ` Tetsuo Handa
@ 2018-09-30 16:57           ` Kees Cook
  2018-09-30 16:57             ` Kees Cook
  1 sibling, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-09-30 16:57 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Casey Schaufler, James Morris, John Johansen, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Sat, Sep 29, 2018 at 7:36 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2018/09/30 3:18, Kees Cook wrote:
>>> Just wondering what is "__lsm_name_##lsm" for...
>>>
>>> +#define DEFINE_LSM(lsm)                                                        \
>>> +       static const char __lsm_name_##lsm[] __initconst                \
>>> +               __aligned(1) = #lsm;                                    \
>>> +       static struct lsm_info __lsm_##lsm                              \
>>> +               __used __section(.lsm_info.init)                        \
>>> +               __aligned(sizeof(unsigned long))                        \
>>> +               = {                                                     \
>>> +                       .name = __lsm_name_##lsm,                       \
>>> +
>>> +#define END_LSM          }
>>
>> I wasn't super happy with the END_LSM thing, but I wanted to be able
>> to declare the name as __initconst, otherwise it needlessly stays in
>> memory after init. That said, it's not a huge deal, and maybe
>> readability trumps a tiny meory savings?
>
> The value of .name field is a few bytes string, and is not sensitive
> information. Keeping such string in non-__initdata section unlikely
> increases total memory pages required for that module.
>
> Unless we need to generate unique address of such string for some reason,
> I think that this saving is pointless.

Okay, sounds good. I will adjust the macro and respin with a v4.

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering
  2018-09-30 16:57           ` Kees Cook
@ 2018-09-30 16:57             ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-09-30 16:57 UTC (permalink / raw)
  To: Tetsuo Handa
  Cc: Casey Schaufler, James Morris, John Johansen, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Sat, Sep 29, 2018 at 7:36 PM, Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2018/09/30 3:18, Kees Cook wrote:
>>> Just wondering what is "__lsm_name_##lsm" for...
>>>
>>> +#define DEFINE_LSM(lsm)                                                        \
>>> +       static const char __lsm_name_##lsm[] __initconst                \
>>> +               __aligned(1) = #lsm;                                    \
>>> +       static struct lsm_info __lsm_##lsm                              \
>>> +               __used __section(.lsm_info.init)                        \
>>> +               __aligned(sizeof(unsigned long))                        \
>>> +               = {                                                     \
>>> +                       .name = __lsm_name_##lsm,                       \
>>> +
>>> +#define END_LSM          }
>>
>> I wasn't super happy with the END_LSM thing, but I wanted to be able
>> to declare the name as __initconst, otherwise it needlessly stays in
>> memory after init. That said, it's not a huge deal, and maybe
>> readability trumps a tiny meory savings?
>
> The value of .name field is a few bytes string, and is not sensitive
> information. Keeping such string in non-__initdata section unlikely
> increases total memory pages required for that module.
>
> Unless we need to generate unique address of such string for some reason,
> I think that this saving is pointless.

Okay, sounds good. I will adjust the macro and respin with a v4.

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-26 18:35     ` Kees Cook
  2018-09-26 18:35       ` Kees Cook
@ 2018-09-30 23:25       ` Steven Rostedt
  2018-09-30 23:25         ` Steven Rostedt
  2018-10-01  1:01         ` Kees Cook
  1 sibling, 2 replies; 164+ messages in thread
From: Steven Rostedt @ 2018-09-30 23:25 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Wed, 26 Sep 2018 11:35:21 -0700
Kees Cook <keescook@chromium.org> wrote:

> On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Mon, 24 Sep 2018 17:18:07 -0700
> > Kees Cook <keescook@chromium.org> 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.  
> >
> > I'm not against the change, but how much are they going to "no longer
> > resemble regular init calls"?  
> 
> My take on "regular" init calls is that they're always run, link-time
> ordered, etc. The changes proposed here will make it so not all
> initialization are run depending on runtime configurations, ordering
> will be flexible, etc.
>

Will it still be a good idea to have a tracepoint for those calls?
Perhaps not an  initcall tracepoint but some other kind?

-- Steve

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-30 23:25       ` Steven Rostedt
@ 2018-09-30 23:25         ` Steven Rostedt
  2018-10-01  1:01         ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: Steven Rostedt @ 2018-09-30 23:25 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Wed, 26 Sep 2018 11:35:21 -0700
Kees Cook <keescook@chromium.org> wrote:

> On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Mon, 24 Sep 2018 17:18:07 -0700
> > Kees Cook <keescook@chromium.org> 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.  
> >
> > I'm not against the change, but how much are they going to "no longer
> > resemble regular init calls"?  
> 
> My take on "regular" init calls is that they're always run, link-time
> ordered, etc. The changes proposed here will make it so not all
> initialization are run depending on runtime configurations, ordering
> will be flexible, etc.
>

Will it still be a good idea to have a tracepoint for those calls?
Perhaps not an  initcall tracepoint but some other kind?

-- Steve

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-30 23:25       ` Steven Rostedt
  2018-09-30 23:25         ` Steven Rostedt
@ 2018-10-01  1:01         ` Kees Cook
  2018-10-01  1:01           ` Kees Cook
  1 sibling, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-10-01  1:01 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Sun, Sep 30, 2018 at 4:25 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 26 Sep 2018 11:35:21 -0700
> Kees Cook <keescook@chromium.org> wrote:
>
>> On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> > On Mon, 24 Sep 2018 17:18:07 -0700
>> > Kees Cook <keescook@chromium.org> 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.
>> >
>> > I'm not against the change, but how much are they going to "no longer
>> > resemble regular init calls"?
>>
>> My take on "regular" init calls is that they're always run, link-time
>> ordered, etc. The changes proposed here will make it so not all
>> initialization are run depending on runtime configurations, ordering
>> will be flexible, etc.
>>
>
> Will it still be a good idea to have a tracepoint for those calls?
> Perhaps not an  initcall tracepoint but some other kind?

I'm not opposed. It could be a follow-up patch, I assume?

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-10-01  1:01         ` Kees Cook
@ 2018-10-01  1:01           ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01  1:01 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Sun, Sep 30, 2018 at 4:25 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 26 Sep 2018 11:35:21 -0700
> Kees Cook <keescook@chromium.org> wrote:
>
>> On Wed, Sep 26, 2018 at 9:35 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> > On Mon, 24 Sep 2018 17:18:07 -0700
>> > Kees Cook <keescook@chromium.org> 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.
>> >
>> > I'm not against the change, but how much are they going to "no longer
>> > resemble regular init calls"?
>>
>> My take on "regular" init calls is that they're always run, link-time
>> ordered, etc. The changes proposed here will make it so not all
>> initialization are run depending on runtime configurations, ordering
>> will be flexible, etc.
>>
>
> Will it still be a good idea to have a tracepoint for those calls?
> Perhaps not an  initcall tracepoint but some other kind?

I'm not opposed. It could be a follow-up patch, I assume?

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization
  2018-09-25  0:18 ` [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 19:53   ` James Morris
  2018-10-01 19:53     ` James Morris
  2018-10-01 21:05   ` John Johansen
  2 siblings, 1 reply; 164+ messages in thread
From: James Morris @ 2018-10-01 19:53 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, 24 Sep 2018, Kees Cook wrote:

> 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>


-- 
James Morris
<jmorris@namei.org>

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

* Re: [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization
  2018-10-01 19:53   ` James Morris
@ 2018-10-01 19:53     ` James Morris
  0 siblings, 0 replies; 164+ messages in thread
From: James Morris @ 2018-10-01 19:53 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, 24 Sep 2018, Kees Cook wrote:

> 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>


-- 
James Morris
<jmorris@namei.org>

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

* Re: [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section
  2018-09-25  0:18 ` [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 19:56   ` James Morris
  2018-10-01 19:56     ` James Morris
  2018-10-01 21:05   ` John Johansen
  2 siblings, 1 reply; 164+ messages in thread
From: James Morris @ 2018-10-01 19:56 UTC (permalink / raw)
  To: Kees Cook
  Cc: Arnd Bergmann, linux-arch, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-kernel

On Mon, 24 Sep 2018, Kees Cook wrote:

> Avoid copy/paste by defining SECURITY_INIT in terms of SECURITY_INITCALL.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arch@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  include/asm-generic/vmlinux.lds.h | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)


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


-- 
James Morris
<jmorris@namei.org>

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

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

On Mon, 24 Sep 2018, Kees Cook wrote:

> Avoid copy/paste by defining SECURITY_INIT in terms of SECURITY_INITCALL.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arch@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  include/asm-generic/vmlinux.lds.h | 13 ++++++-------
>  1 file changed, 6 insertions(+), 7 deletions(-)


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


-- 
James Morris
<jmorris@namei.org>

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

* Re: [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info
  2018-09-25  0:18 ` [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 19:57   ` James Morris
  2018-10-01 19:57     ` James Morris
  2018-10-01 21:06   ` John Johansen
  2 siblings, 1 reply; 164+ messages in thread
From: James Morris @ 2018-10-01 19:57 UTC (permalink / raw)
  To: Kees Cook
  Cc: Arnd Bergmann, Serge E. Hallyn, Ard Biesheuvel, linux-arch,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, linux-doc, linux-kernel

On Mon, 24 Sep 2018, Kees Cook wrote:

> In preparation for switching from initcall to just a regular set of
> pointers in a section, rename the internal section name.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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


-- 
James Morris
<jmorris@namei.org>

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

* Re: [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info
  2018-10-01 19:57   ` James Morris
@ 2018-10-01 19:57     ` James Morris
  0 siblings, 0 replies; 164+ messages in thread
From: James Morris @ 2018-10-01 19:57 UTC (permalink / raw)
  To: Kees Cook
  Cc: Arnd Bergmann, Serge E. Hallyn, Ard Biesheuvel, linux-arch,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, linux-doc, linux-kernel

On Mon, 24 Sep 2018, Kees Cook wrote:

> In preparation for switching from initcall to just a regular set of
> pointers in a section, rename the internal section name.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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


-- 
James Morris
<jmorris@namei.org>

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

* Re: [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info
  2018-09-25  0:18 ` [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 19:59   ` James Morris
  2018-10-01 19:59     ` James Morris
  2018-10-01 21:08   ` John Johansen
  2 siblings, 1 reply; 164+ messages in thread
From: James Morris @ 2018-10-01 19:59 UTC (permalink / raw)
  To: Kees Cook
  Cc: Serge E. Hallyn, Ard Biesheuvel, Paul Moore,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Stephen Smalley, Schaufler, Casey, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 24 Sep 2018, Kees Cook wrote:

> 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.
> 
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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


-- 
James Morris
<jmorris@namei.org>

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

* Re: [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info
  2018-10-01 19:59   ` James Morris
@ 2018-10-01 19:59     ` James Morris
  0 siblings, 0 replies; 164+ messages in thread
From: James Morris @ 2018-10-01 19:59 UTC (permalink / raw)
  To: Kees Cook
  Cc: Serge E. Hallyn, Ard Biesheuvel, Paul Moore,
	linux-security-module, Casey Schaufler, John Johansen,
	Tetsuo Handa, Stephen Smalley, Schaufler, Casey, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On Mon, 24 Sep 2018, Kees Cook wrote:

> 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.
> 
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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


-- 
James Morris
<jmorris@namei.org>

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

* Re: [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization
  2018-09-25  0:18 ` [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 19:53   ` James Morris
@ 2018-10-01 21:05   ` John Johansen
  2018-10-01 21:05     ` John Johansen
  2 siblings, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:05 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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.
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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.
> 

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

* Re: [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section
  2018-09-25  0:18 ` [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 19:56   ` James Morris
@ 2018-10-01 21:05   ` John Johansen
  2018-10-01 21:05     ` John Johansen
  2 siblings, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:05 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Arnd Bergmann, linux-arch, Casey Schaufler, Tetsuo Handa,
	Paul Moore, Stephen Smalley, Schaufler, Casey, LSM,
	Jonathan Corbet, linux-doc, linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> Avoid copy/paste by defining SECURITY_INIT in terms of SECURITY_INITCALL.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arch@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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);							\
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> Avoid copy/paste by defining SECURITY_INIT in terms of SECURITY_INITCALL.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arch@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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);							\
> 

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

* Re: [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info
  2018-09-25  0:18 ` [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 19:57   ` James Morris
@ 2018-10-01 21:06   ` John Johansen
  2018-10-01 21:06     ` John Johansen
  2 siblings, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:06 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Arnd Bergmann, Serge E. Hallyn, Ard Biesheuvel, linux-arch,
	linux-security-module, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, Jonathan Corbet, linux-doc,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> In preparation for switching from initcall to just a regular set of
> pointers in a section, rename the internal section name.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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();
> 

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

* Re: [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info
  2018-10-01 21:06   ` John Johansen
@ 2018-10-01 21:06     ` John Johansen
  0 siblings, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:06 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Arnd Bergmann, Serge E. Hallyn, Ard Biesheuvel, linux-arch,
	linux-security-module, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, Jonathan Corbet, linux-doc,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> In preparation for switching from initcall to just a regular set of
> pointers in a section, rename the internal section name.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: linux-arch@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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();
> 

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-09-25  0:18 ` [PATCH security-next v3 04/29] LSM: Remove initcall tracing Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-09-26 16:35   ` Steven Rostedt
@ 2018-10-01 21:07   ` John Johansen
  2018-10-01 21:07     ` John Johansen
  2018-10-01 21:23     ` Steven Rostedt
  2 siblings, 2 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:07 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Serge E. Hallyn, Abderrahmane Benbachir, Steven Rostedt,
	linux-security-module, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, Jonathan Corbet, linux-doc,
	linux-arch, linux-kernel

On 09/24/2018 05:18 PM, 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.
> 
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


Reviewed-by: John Johansen <john.johansen@canonical.com>

though I do think it would be a good idea to add a new set
of trace points, but that can come as a separate patch

> ---
>  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++;
>  	}
>  }
> 

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-10-01 21:07   ` John Johansen
@ 2018-10-01 21:07     ` John Johansen
  2018-10-01 21:23     ` Steven Rostedt
  1 sibling, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:07 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Serge E. Hallyn, Abderrahmane Benbachir, Steven Rostedt,
	linux-security-module, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, Jonathan Corbet, linux-doc,
	linux-arch, linux-kernel

On 09/24/2018 05:18 PM, 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.
> 
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


Reviewed-by: John Johansen <john.johansen@canonical.com>

though I do think it would be a good idea to add a new set
of trace points, but that can come as a separate patch

> ---
>  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++;
>  	}
>  }
> 

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

* Re: [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info
  2018-09-25  0:18 ` [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 19:59   ` James Morris
@ 2018-10-01 21:08   ` John Johansen
  2018-10-01 21:08     ` John Johansen
  2 siblings, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:08 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Serge E. Hallyn, Ard Biesheuvel, Paul Moore,
	linux-security-module, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, Jonathan Corbet, linux-doc,
	linux-arch, linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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.
> 
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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..ad04761e5587 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);
> +};
> +
> +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;
>  }
> 

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

* Re: [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info
  2018-10-01 21:08   ` John Johansen
@ 2018-10-01 21:08     ` John Johansen
  0 siblings, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:08 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Serge E. Hallyn, Ard Biesheuvel, Paul Moore,
	linux-security-module, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, Jonathan Corbet, linux-doc,
	linux-arch, linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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.
> 
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: linux-security-module@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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..ad04761e5587 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);
> +};
> +
> +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;
>  }
> 

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

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

On 09/24/2018 05:18 PM, 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.
> 
> Cc: linux-arch@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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						\
>  	}
>  
> 

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

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

On 09/24/2018 05:18 PM, 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.
> 
> Cc: linux-arch@vger.kernel.org
> Signed-off-by: Kees Cook <keescook@chromium.org>


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						\
>  	}
>  
> 

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

* Re: [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM()
  2018-09-25  0:18 ` [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:12   ` John Johansen
  2018-10-01 21:12     ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:12 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Serge E. Hallyn, Paul Moore, Stephen Smalley, Casey Schaufler,
	Tetsuo Handa, Mimi Zohar, linux-security-module, selinux,
	Schaufler, Casey, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, 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.
> 
> Cc: John Johansen <john.johansen@canonical.com>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Stephen Smalley <sds@tycho.nsa.gov>
> Cc: Casey Schaufler <casey@schaufler-ca.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
> Cc: linux-security-module@vger.kernel.org
> Cc: selinux@tycho.nsa.gov
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  include/linux/lsm_hooks.h  | 6 ++++--
>  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, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index ad04761e5587..02ec717189f9 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -2045,11 +2045,13 @@ 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, }
> +		= {							\
> +
> +#define END_LSM	  }
>  

I am with Tetsuo on this one, I really don't like the END_LSM thing.

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

* Re: [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM()
  2018-10-01 21:12   ` John Johansen
@ 2018-10-01 21:12     ` John Johansen
  0 siblings, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:12 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Serge E. Hallyn, Paul Moore, Stephen Smalley, Casey Schaufler,
	Tetsuo Handa, Mimi Zohar, linux-security-module, selinux,
	Schaufler, Casey, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, 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.
> 
> Cc: John Johansen <john.johansen@canonical.com>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Stephen Smalley <sds@tycho.nsa.gov>
> Cc: Casey Schaufler <casey@schaufler-ca.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
> Cc: linux-security-module@vger.kernel.org
> Cc: selinux@tycho.nsa.gov
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
>  include/linux/lsm_hooks.h  | 6 ++++--
>  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, 19 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index ad04761e5587..02ec717189f9 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -2045,11 +2045,13 @@ 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, }
> +		= {							\
> +
> +#define END_LSM	  }
>  

I am with Tetsuo on this one, I really don't like the END_LSM thing.

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

* Re: [PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info
  2018-09-25  0:18 ` [PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:13   ` John Johansen
  2018-10-01 21:13     ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:13 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	linux-doc, linux-arch, linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> In preparation for making LSM selections outside of the LSMs, include
> the name of LSMs in struct lsm_info.
> 
> Cc: James Morris <james.morris@microsoft.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>

I'll leave this one until after the changes you have already discussed with Tetsuo around, END_LSM and .name

> ---
>  include/linux/lsm_hooks.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 02ec717189f9..543636f18152 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -2040,16 +2040,20 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
>  				char *lsm);
>  
>  struct lsm_info {
> +	const char *name;	/* Populated automatically. */
>  	int (*init)(void);
>  };
>  
>  extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
>  
>  #define DEFINE_LSM(lsm)							\
> +	static const char __lsm_name_##lsm[] __initconst		\
> +		__aligned(1) = #lsm;					\
>  	static struct lsm_info __lsm_##lsm				\
>  		__used __section(.lsm_info.init)			\
>  		__aligned(sizeof(unsigned long))			\
>  		= {							\
> +			.name = __lsm_name_##lsm,			\
>  
>  #define END_LSM	  }
>  
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> In preparation for making LSM selections outside of the LSMs, include
> the name of LSMs in struct lsm_info.
> 
> Cc: James Morris <james.morris@microsoft.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>

I'll leave this one until after the changes you have already discussed with Tetsuo around, END_LSM and .name

> ---
>  include/linux/lsm_hooks.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 02ec717189f9..543636f18152 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -2040,16 +2040,20 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
>  				char *lsm);
>  
>  struct lsm_info {
> +	const char *name;	/* Populated automatically. */
>  	int (*init)(void);
>  };
>  
>  extern struct lsm_info __start_lsm_info[], __end_lsm_info[];
>  
>  #define DEFINE_LSM(lsm)							\
> +	static const char __lsm_name_##lsm[] __initconst		\
> +		__aligned(1) = #lsm;					\
>  	static struct lsm_info __lsm_##lsm				\
>  		__used __section(.lsm_info.init)			\
>  		__aligned(sizeof(unsigned long))			\
>  		= {							\
> +			.name = __lsm_name_##lsm,			\
>  
>  #define END_LSM	  }
>  
> 

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

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

On 09/24/2018 05:18 PM, 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: 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..ee49b921d750 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 bool debug __initdata;
> +#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;
> 

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

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

On 09/24/2018 05:18 PM, 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: 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..ee49b921d750 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 bool debug __initdata;
> +#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;
> 

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

* Re: [PATCH security-next v3 10/29] LSM: Don't ignore initialization failures
  2018-09-25  0:18 ` [PATCH security-next v3 10/29] LSM: Don't ignore initialization failures Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:14   ` John Johansen
  2018-10-01 21:14     ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:14 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> LSM initialization failures have traditionally been ignored. We should
> at least WARN when something goes wrong.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>

about time

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 ee49b921d750..1f055936a746 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -55,10 +55,12 @@ static bool debug __initdata;
>  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);
>  	}
>  }
>  
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> LSM initialization failures have traditionally been ignored. We should
> at least WARN when something goes wrong.
> 
> Signed-off-by: Kees Cook <keescook@chromium.org>

about time

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 ee49b921d750..1f055936a746 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -55,10 +55,12 @@ static bool debug __initdata;
>  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);
>  	}
>  }
>  
> 

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

* Re: [PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR
  2018-09-25  0:18 ` [PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:15   ` John Johansen
  2018-10-01 21:15     ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:15 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 543636f18152..5056f7374b3d 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;	/* Populated automatically. */
> +	unsigned long flags;	/* Optional: flags describing LSM */
>  	int (*init)(void);
>  };
>  
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 7fa7b4464cf4..4c5f63e9aeba 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1607,5 +1607,6 @@ static int __init apparmor_init(void)
>  }
>  
>  DEFINE_LSM(apparmor)
> +	.flags = LSM_FLAG_LEGACY_MAJOR,
>  	.init = apparmor_init,
>  END_LSM;
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 469a90806bc6..615cf6498c0f 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)
> +	.flags = LSM_FLAG_LEGACY_MAJOR,
>  	.init = selinux_init,
>  END_LSM;
>  
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 1e1ace718e75..4aef844fc0e2 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)
> +	.flags = LSM_FLAG_LEGACY_MAJOR,
>  	.init = smack_init,
>  END_LSM;
> diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
> index a280d4eab456..528b6244a648 100644
> --- a/security/tomoyo/tomoyo.c
> +++ b/security/tomoyo/tomoyo.c
> @@ -551,5 +551,6 @@ static int __init tomoyo_init(void)
>  }
>  
>  DEFINE_LSM(tomoyo)
> +	.flags = LSM_FLAG_LEGACY_MAJOR,
>  	.init = tomoyo_init,
>  END_LSM;
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 543636f18152..5056f7374b3d 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;	/* Populated automatically. */
> +	unsigned long flags;	/* Optional: flags describing LSM */
>  	int (*init)(void);
>  };
>  
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 7fa7b4464cf4..4c5f63e9aeba 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1607,5 +1607,6 @@ static int __init apparmor_init(void)
>  }
>  
>  DEFINE_LSM(apparmor)
> +	.flags = LSM_FLAG_LEGACY_MAJOR,
>  	.init = apparmor_init,
>  END_LSM;
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 469a90806bc6..615cf6498c0f 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)
> +	.flags = LSM_FLAG_LEGACY_MAJOR,
>  	.init = selinux_init,
>  END_LSM;
>  
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 1e1ace718e75..4aef844fc0e2 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)
> +	.flags = LSM_FLAG_LEGACY_MAJOR,
>  	.init = smack_init,
>  END_LSM;
> diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
> index a280d4eab456..528b6244a648 100644
> --- a/security/tomoyo/tomoyo.c
> +++ b/security/tomoyo/tomoyo.c
> @@ -551,5 +551,6 @@ static int __init tomoyo_init(void)
>  }
>  
>  DEFINE_LSM(tomoyo)
> +	.flags = LSM_FLAG_LEGACY_MAJOR,
>  	.init = tomoyo_init,
>  END_LSM;
> 

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

* Re: [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization
  2018-09-25  0:18 ` [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:17   ` John Johansen
  2018-10-01 21:17     ` John Johansen
  2018-10-01 22:03     ` Kees Cook
  1 sibling, 2 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:17 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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>

I know its already being done, but I don't like splitting the init
order

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 1f055936a746..a886a978214a 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -52,12 +52,30 @@ static bool debug __initdata;
>  			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.
>  	 */
> 

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

* Re: [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization
  2018-10-01 21:17   ` John Johansen
@ 2018-10-01 21:17     ` John Johansen
  2018-10-01 22:03     ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:17 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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>

I know its already being done, but I don't like splitting the init
order

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 1f055936a746..a886a978214a 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -52,12 +52,30 @@ static bool debug __initdata;
>  			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.
>  	 */
> 

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

* Re: [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce"
  2018-09-25  0:18 ` [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce" Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:17   ` John Johansen
  2018-10-01 21:17     ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:17 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 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
> 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: 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");
> 

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

* Re: [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce"
  2018-10-01 21:17   ` John Johansen
@ 2018-10-01 21:17     ` John Johansen
  0 siblings, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:17 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 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
> 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: 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");
> 

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-09-25  0:18 ` [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:18   ` John Johansen
  2018-10-01 21:18     ` John Johansen
  2018-10-01 21:47   ` James Morris
  2 siblings, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:18 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 5056f7374b3d..2a41e8e6f6e5 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;	/* Populated automatically. */
>  	unsigned long flags;	/* Optional: flags describing LSM */
> +	int *enabled;		/* Optional: NULL means enabled. */
>  	int (*init)(void);
>  };
>  
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 4c5f63e9aeba..d03133a267f2 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)
>  {
> @@ -1608,5 +1608,6 @@ static int __init apparmor_init(void)
>  
>  DEFINE_LSM(apparmor)
>  	.flags = LSM_FLAG_LEGACY_MAJOR,
> +	.enabled = &apparmor_enabled,
>  	.init = apparmor_init,
>  END_LSM;
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 615cf6498c0f..3f999ed98cfd 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)
>  	.flags = LSM_FLAG_LEGACY_MAJOR,
> +	.enabled = &selinux_enabled,
>  	.init = selinux_init,
>  END_LSM;
>  
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 5056f7374b3d..2a41e8e6f6e5 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;	/* Populated automatically. */
>  	unsigned long flags;	/* Optional: flags describing LSM */
> +	int *enabled;		/* Optional: NULL means enabled. */
>  	int (*init)(void);
>  };
>  
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 4c5f63e9aeba..d03133a267f2 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)
>  {
> @@ -1608,5 +1608,6 @@ static int __init apparmor_init(void)
>  
>  DEFINE_LSM(apparmor)
>  	.flags = LSM_FLAG_LEGACY_MAJOR,
> +	.enabled = &apparmor_enabled,
>  	.init = apparmor_init,
>  END_LSM;
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 615cf6498c0f..3f999ed98cfd 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)
>  	.flags = LSM_FLAG_LEGACY_MAJOR,
> +	.enabled = &selinux_enabled,
>  	.init = selinux_init,
>  END_LSM;
>  
> 

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

* Re: [PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs
  2018-09-25  0:18 ` [PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:18   ` John Johansen
  2018-10-01 21:18     ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:18 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 2a41e8e6f6e5..95798f212dbf 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -2091,7 +2091,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 d03133a267f2..5399c2f03536 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 a886a978214a..056b36cf6245 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -52,33 +52,78 @@ static bool debug __initdata;
>  			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 3f999ed98cfd..409a9252aeb6 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 4aef844fc0e2..e79fad43a8e3 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 528b6244a648..39bb994ebe09 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");
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 2a41e8e6f6e5..95798f212dbf 100644
> --- a/include/linux/lsm_hooks.h
> +++ b/include/linux/lsm_hooks.h
> @@ -2091,7 +2091,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 d03133a267f2..5399c2f03536 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 a886a978214a..056b36cf6245 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -52,33 +52,78 @@ static bool debug __initdata;
>  			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 3f999ed98cfd..409a9252aeb6 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 4aef844fc0e2..e79fad43a8e3 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 528b6244a648..39bb994ebe09 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");
> 

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

* Re: [PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling
  2018-09-25  0:18 ` [PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:22   ` John Johansen
  2018-10-01 21:22     ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:22 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 056b36cf6245..a8107d54b3d3 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -54,17 +54,46 @@ static bool debug __initdata;
>  
>  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.
>  	 */
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 056b36cf6245..a8107d54b3d3 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -54,17 +54,46 @@ static bool debug __initdata;
>  
>  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.
>  	 */
> 

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-10-01 21:07   ` John Johansen
  2018-10-01 21:07     ` John Johansen
@ 2018-10-01 21:23     ` Steven Rostedt
  2018-10-01 21:23       ` Steven Rostedt
  2018-10-01 22:38       ` Kees Cook
  1 sibling, 2 replies; 164+ messages in thread
From: Steven Rostedt @ 2018-10-01 21:23 UTC (permalink / raw)
  To: John Johansen
  Cc: Kees Cook, James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, Jonathan Corbet, linux-doc,
	linux-arch, linux-kernel

On Mon, 1 Oct 2018 14:07:55 -0700
John Johansen <john.johansen@canonical.com> wrote:

> On 09/24/2018 05:18 PM, 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.
> > 
> > Cc: James Morris <jmorris@namei.org>
> > Cc: "Serge E. Hallyn" <serge@hallyn.com>
> > Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
> > Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
> > Cc: linux-security-module@vger.kernel.org
> > Signed-off-by: Kees Cook <keescook@chromium.org>  
> 
> 
> Reviewed-by: John Johansen <john.johansen@canonical.com>
> 
> though I do think it would be a good idea to add a new set
> of trace points, but that can come as a separate patch
> 
>

Agreed.

-- Steve

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-10-01 21:23     ` Steven Rostedt
@ 2018-10-01 21:23       ` Steven Rostedt
  2018-10-01 22:38       ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: Steven Rostedt @ 2018-10-01 21:23 UTC (permalink / raw)
  To: John Johansen
  Cc: Kees Cook, James Morris, Serge E. Hallyn, Abderrahmane Benbachir,
	linux-security-module, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, Jonathan Corbet, linux-doc,
	linux-arch, linux-kernel

On Mon, 1 Oct 2018 14:07:55 -0700
John Johansen <john.johansen@canonical.com> wrote:

> On 09/24/2018 05:18 PM, 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.
> > 
> > Cc: James Morris <jmorris@namei.org>
> > Cc: "Serge E. Hallyn" <serge@hallyn.com>
> > Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
> > Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
> > Cc: linux-security-module@vger.kernel.org
> > Signed-off-by: Kees Cook <keescook@chromium.org>  
> 
> 
> Reviewed-by: John Johansen <john.johansen@canonical.com>
> 
> though I do think it would be a good idea to add a new set
> of trace points, but that can come as a separate patch
> 
>

Agreed.

-- Steve

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

* Re: [PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE
  2018-09-25  0:18 ` [PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:34   ` John Johansen
  2018-10-01 21:34     ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:34 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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>

The patch is fine but I am not sure I like the behavior. I much prefer
that its an explicit list and nothing is left to implicit. That is
if there is a conflict between the list and the LSM-specific config
the LSM is disabled.



> ---
>  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 95798f212dbf..ab23f1bc6d77 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;	/* Populated automatically. */
>  	unsigned long flags;	/* Optional: flags describing LSM */
> -	int *enabled;		/* Optional: NULL means enabled. */
> +	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
>  	int (*init)(void);
>  };
>  
> diff --git a/security/Kconfig b/security/Kconfig
> index 27d8b2688f75..71306b046270 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-separate 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 a8107d54b3d3..7ecb9879a863 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 bool debug __initdata;
>  #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);
>  }
>  
>  /**
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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>

The patch is fine but I am not sure I like the behavior. I much prefer
that its an explicit list and nothing is left to implicit. That is
if there is a conflict between the list and the LSM-specific config
the LSM is disabled.



> ---
>  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 95798f212dbf..ab23f1bc6d77 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;	/* Populated automatically. */
>  	unsigned long flags;	/* Optional: flags describing LSM */
> -	int *enabled;		/* Optional: NULL means enabled. */
> +	int *enabled;		/* Optional: NULL checks CONFIG_LSM_ENABLE */
>  	int (*init)(void);
>  };
>  
> diff --git a/security/Kconfig b/security/Kconfig
> index 27d8b2688f75..71306b046270 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-separate 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 a8107d54b3d3..7ecb9879a863 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 bool debug __initdata;
>  #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);
>  }
>  
>  /**
> 

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-09-25  0:18 ` [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:46   ` John Johansen
  2018-10-01 21:46     ` John Johansen
  2018-10-01 22:27     ` Kees Cook
  1 sibling, 2 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:46 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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>

I don't like this. It brings about conflicting kernel params that are
bound to confuse users. Its pretty easy for a user to understand that
when they specify a parameter manually at boot, that  it overrides the
build time default. But conflicting kernel parameters are a lot harder
to deal with.

I prefer a plain enabled= list being an override of the default build
time value. Where conflicts with LSM-specific configs always result in
the LSM being disabled with a complaint about the conflict.

Though I have yet to be convinced its worth the cost, I do recognize
it is sometimes convenient to disable a single LSM, instead of typing
in a whole list of what to enable. If we have to have conflicting
kernel parameters I would prefer that the conflict throw up a warning
and leaving the LSM with the conflicting config disabled.



> ---
>  .../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 71306b046270..1a82a006cc62 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -282,7 +282,9 @@ config LSM_ENABLE
>  	help
>  	  A comma-separate 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 7ecb9879a863..456a3f73bc36 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;
> 

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 21:46   ` John Johansen
@ 2018-10-01 21:46     ` John Johansen
  2018-10-01 22:27     ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:46 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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>

I don't like this. It brings about conflicting kernel params that are
bound to confuse users. Its pretty easy for a user to understand that
when they specify a parameter manually at boot, that  it overrides the
build time default. But conflicting kernel parameters are a lot harder
to deal with.

I prefer a plain enabled= list being an override of the default build
time value. Where conflicts with LSM-specific configs always result in
the LSM being disabled with a complaint about the conflict.

Though I have yet to be convinced its worth the cost, I do recognize
it is sometimes convenient to disable a single LSM, instead of typing
in a whole list of what to enable. If we have to have conflicting
kernel parameters I would prefer that the conflict throw up a warning
and leaving the LSM with the conflicting config disabled.



> ---
>  .../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 71306b046270..1a82a006cc62 100644
> --- a/security/Kconfig
> +++ b/security/Kconfig
> @@ -282,7 +282,9 @@ config LSM_ENABLE
>  	help
>  	  A comma-separate 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 7ecb9879a863..456a3f73bc36 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;
> 

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

* Re: [PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic
  2018-09-25  0:18 ` [PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic Kees Cook
  2018-09-25  0:18   ` Kees Cook
@ 2018-10-01 21:47   ` John Johansen
  2018-10-01 21:47     ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 21:47 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, linux-doc, linux-arch,
	linux-kernel

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 456a3f73bc36..e325fcc41f00 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)
> 

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

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

On 09/24/2018 05:18 PM, Kees Cook wrote:
> 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: 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 456a3f73bc36..e325fcc41f00 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)
> 

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-09-25  0:18 ` [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state Kees Cook
  2018-09-25  0:18   ` Kees Cook
  2018-10-01 21:18   ` John Johansen
@ 2018-10-01 21:47   ` James Morris
  2018-10-01 21:47     ` James Morris
  2018-10-01 21:56     ` Kees Cook
  2 siblings, 2 replies; 164+ messages in thread
From: James Morris @ 2018-10-01 21:47 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, 24 Sep 2018, Kees Cook wrote:

> 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>
> ---
>  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 5056f7374b3d..2a41e8e6f6e5 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;	/* Populated automatically. */
>  	unsigned long flags;	/* Optional: flags describing LSM */
> +	int *enabled;		/* Optional: NULL means enabled. */

This seems potentially confusing.

Perhaps initialize 'enabled' to a default int pointer, like:

	static int lsm_default_enabled = 1;

Then,

	DEFINE_LSM(foobar)
	flags = LSM_FLAG_LEGACY_MAJOR,
	.enabled = &lsm_default_enabled,
	.init = foobar_init,
	END_LSM;



>  	int (*init)(void);
>  };
>  
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 4c5f63e9aeba..d03133a267f2 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)
>  {
> @@ -1608,5 +1608,6 @@ static int __init apparmor_init(void)
>  
>  DEFINE_LSM(apparmor)
>  	.flags = LSM_FLAG_LEGACY_MAJOR,
> +	.enabled = &apparmor_enabled,
>  	.init = apparmor_init,
>  END_LSM;
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 615cf6498c0f..3f999ed98cfd 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)
>  	.flags = LSM_FLAG_LEGACY_MAJOR,
> +	.enabled = &selinux_enabled,
>  	.init = selinux_init,
>  END_LSM;
>  
> 

-- 
James Morris
<jmorris@namei.org>

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-10-01 21:47   ` James Morris
@ 2018-10-01 21:47     ` James Morris
  2018-10-01 21:56     ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: James Morris @ 2018-10-01 21:47 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, 24 Sep 2018, Kees Cook wrote:

> 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>
> ---
>  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 5056f7374b3d..2a41e8e6f6e5 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;	/* Populated automatically. */
>  	unsigned long flags;	/* Optional: flags describing LSM */
> +	int *enabled;		/* Optional: NULL means enabled. */

This seems potentially confusing.

Perhaps initialize 'enabled' to a default int pointer, like:

	static int lsm_default_enabled = 1;

Then,

	DEFINE_LSM(foobar)
	flags = LSM_FLAG_LEGACY_MAJOR,
	.enabled = &lsm_default_enabled,
	.init = foobar_init,
	END_LSM;



>  	int (*init)(void);
>  };
>  
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 4c5f63e9aeba..d03133a267f2 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)
>  {
> @@ -1608,5 +1608,6 @@ static int __init apparmor_init(void)
>  
>  DEFINE_LSM(apparmor)
>  	.flags = LSM_FLAG_LEGACY_MAJOR,
> +	.enabled = &apparmor_enabled,
>  	.init = apparmor_init,
>  END_LSM;
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 615cf6498c0f..3f999ed98cfd 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)
>  	.flags = LSM_FLAG_LEGACY_MAJOR,
> +	.enabled = &selinux_enabled,
>  	.init = selinux_init,
>  END_LSM;
>  
> 

-- 
James Morris
<jmorris@namei.org>

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-10-01 21:47   ` James Morris
  2018-10-01 21:47     ` James Morris
@ 2018-10-01 21:56     ` Kees Cook
  2018-10-01 21:56       ` Kees Cook
  2018-10-01 22:20       ` John Johansen
  1 sibling, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 21:56 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 Mon, Oct 1, 2018 at 2:47 PM, James Morris <jmorris@namei.org> wrote:
> On Mon, 24 Sep 2018, Kees Cook wrote:
>
>> 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>
>> ---
>>  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 5056f7374b3d..2a41e8e6f6e5 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;       /* Populated automatically. */
>>       unsigned long flags;    /* Optional: flags describing LSM */
>> +     int *enabled;           /* Optional: NULL means enabled. */
>
> This seems potentially confusing.
>
> Perhaps initialize 'enabled' to a default int pointer, like:
>
>         static int lsm_default_enabled = 1;
>
> Then,
>
>         DEFINE_LSM(foobar)
>         flags = LSM_FLAG_LEGACY_MAJOR,
>         .enabled = &lsm_default_enabled,
>         .init = foobar_init,
>         END_LSM;

The reason I didn't do this is because there are only two LSMs that
expose this "enabled" variable, so I didn't like making the other LSMs
have to declare this. Internally, though, this is exactly what the
infrastructure does: if it finds a NULL, it aims it at
&lsm_default_enabled (in a later patch).

However, it seems more discussion is needed on the "enable" bit of
this, so I'll reply to John in a moment...

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-10-01 21:56     ` Kees Cook
@ 2018-10-01 21:56       ` Kees Cook
  2018-10-01 22:20       ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 21:56 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 Mon, Oct 1, 2018 at 2:47 PM, James Morris <jmorris@namei.org> wrote:
> On Mon, 24 Sep 2018, Kees Cook wrote:
>
>> 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>
>> ---
>>  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 5056f7374b3d..2a41e8e6f6e5 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;       /* Populated automatically. */
>>       unsigned long flags;    /* Optional: flags describing LSM */
>> +     int *enabled;           /* Optional: NULL means enabled. */
>
> This seems potentially confusing.
>
> Perhaps initialize 'enabled' to a default int pointer, like:
>
>         static int lsm_default_enabled = 1;
>
> Then,
>
>         DEFINE_LSM(foobar)
>         flags = LSM_FLAG_LEGACY_MAJOR,
>         .enabled = &lsm_default_enabled,
>         .init = foobar_init,
>         END_LSM;

The reason I didn't do this is because there are only two LSMs that
expose this "enabled" variable, so I didn't like making the other LSMs
have to declare this. Internally, though, this is exactly what the
infrastructure does: if it finds a NULL, it aims it at
&lsm_default_enabled (in a later patch).

However, it seems more discussion is needed on the "enable" bit of
this, so I'll reply to John in a moment...

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization
  2018-10-01 21:17   ` John Johansen
  2018-10-01 21:17     ` John Johansen
@ 2018-10-01 22:03     ` Kees Cook
  2018-10-01 22:03       ` Kees Cook
  1 sibling, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-10-01 22:03 UTC (permalink / raw)
  To: John Johansen
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 2:17 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 09/24/2018 05:18 PM, Kees Cook wrote:
>> 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>
>
> I know its already being done, but I don't like splitting the init
> order

Can you describe what you mean here? Do you mean having two init
functions? This is only done temporarily while the other pieces are
reorganized. The later patches reintegrate this. (Before this series,
we effectively had three implicit init paths: minor, major, and
integrity, so even this patch "alone" is an improvement IMO.)

Thanks for the reviews!

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization
  2018-10-01 22:03     ` Kees Cook
@ 2018-10-01 22:03       ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 22:03 UTC (permalink / raw)
  To: John Johansen
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 2:17 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 09/24/2018 05:18 PM, Kees Cook wrote:
>> 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>
>
> I know its already being done, but I don't like splitting the init
> order

Can you describe what you mean here? Do you mean having two init
functions? This is only done temporarily while the other pieces are
reorganized. The later patches reintegrate this. (Before this series,
we effectively had three implicit init paths: minor, major, and
integrity, so even this patch "alone" is an improvement IMO.)

Thanks for the reviews!

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-10-01 21:56     ` Kees Cook
  2018-10-01 21:56       ` Kees Cook
@ 2018-10-01 22:20       ` John Johansen
  2018-10-01 22:20         ` John Johansen
  2018-10-01 22:29         ` Kees Cook
  1 sibling, 2 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 22:20 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/01/2018 02:56 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 2:47 PM, James Morris <jmorris@namei.org> wrote:
>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>
>>> 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>
>>> ---
>>>  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 5056f7374b3d..2a41e8e6f6e5 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;       /* Populated automatically. */
>>>       unsigned long flags;    /* Optional: flags describing LSM */
>>> +     int *enabled;           /* Optional: NULL means enabled. */
>>
>> This seems potentially confusing.
>>
>> Perhaps initialize 'enabled' to a default int pointer, like:
>>
>>         static int lsm_default_enabled = 1;
>>
>> Then,
>>
>>         DEFINE_LSM(foobar)
>>         flags = LSM_FLAG_LEGACY_MAJOR,
>>         .enabled = &lsm_default_enabled,
>>         .init = foobar_init,
>>         END_LSM;
> 
> The reason I didn't do this is because there are only two LSMs that
> expose this "enabled" variable, so I didn't like making the other LSMs
> have to declare this. Internally, though, this is exactly what the
> infrastructure does: if it finds a NULL, it aims it at
> &lsm_default_enabled (in a later patch).
> 
> However, it seems more discussion is needed on the "enable" bit of
> this, so I'll reply to John in a moment...
> 
fwiw the apparmor.enabled config is really only a meant to be used to
disable apparmor. I'd drop it entirely except its part of the userspace
api now and needs to show up in

  /sys/module/apparmor/parameters/enabled

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-10-01 22:20       ` John Johansen
@ 2018-10-01 22:20         ` John Johansen
  2018-10-01 22:29         ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 22:20 UTC (permalink / raw)
  To: Kees Cook, James Morris
  Cc: Casey Schaufler, Tetsuo Handa, Paul Moore, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/01/2018 02:56 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 2:47 PM, James Morris <jmorris@namei.org> wrote:
>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>
>>> 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>
>>> ---
>>>  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 5056f7374b3d..2a41e8e6f6e5 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;       /* Populated automatically. */
>>>       unsigned long flags;    /* Optional: flags describing LSM */
>>> +     int *enabled;           /* Optional: NULL means enabled. */
>>
>> This seems potentially confusing.
>>
>> Perhaps initialize 'enabled' to a default int pointer, like:
>>
>>         static int lsm_default_enabled = 1;
>>
>> Then,
>>
>>         DEFINE_LSM(foobar)
>>         flags = LSM_FLAG_LEGACY_MAJOR,
>>         .enabled = &lsm_default_enabled,
>>         .init = foobar_init,
>>         END_LSM;
> 
> The reason I didn't do this is because there are only two LSMs that
> expose this "enabled" variable, so I didn't like making the other LSMs
> have to declare this. Internally, though, this is exactly what the
> infrastructure does: if it finds a NULL, it aims it at
> &lsm_default_enabled (in a later patch).
> 
> However, it seems more discussion is needed on the "enable" bit of
> this, so I'll reply to John in a moment...
> 
fwiw the apparmor.enabled config is really only a meant to be used to
disable apparmor. I'd drop it entirely except its part of the userspace
api now and needs to show up in

  /sys/module/apparmor/parameters/enabled

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 21:46   ` John Johansen
  2018-10-01 21:46     ` John Johansen
@ 2018-10-01 22:27     ` Kees Cook
  2018-10-01 22:27       ` Kees Cook
  2018-10-01 22:48       ` John Johansen
  1 sibling, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 22:27 UTC (permalink / raw)
  To: John Johansen, Paul Moore
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 09/24/2018 05:18 PM, Kees Cook wrote:
>> 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>
>
> I don't like this. It brings about conflicting kernel params that are
> bound to confuse users. Its pretty easy for a user to understand that
> when they specify a parameter manually at boot, that  it overrides the
> build time default. But conflicting kernel parameters are a lot harder
> to deal with.
>
> I prefer a plain enabled= list being an override of the default build
> time value. Where conflicts with LSM-specific configs always result in
> the LSM being disabled with a complaint about the conflict.
>
> Though I have yet to be convinced its worth the cost, I do recognize
> it is sometimes convenient to disable a single LSM, instead of typing
> in a whole list of what to enable. If we have to have conflicting
> kernel parameters I would prefer that the conflict throw up a warning
> and leaving the LSM with the conflicting config disabled.

Alright, let's drill down a bit more. I thought I had all the
requirements sorted out here. :)

AppArmor and SELinux are "special" here in that they have both:

- CONFIG for enable-ness
- boot param for enable-ness

Now, the way this worked in the past was that combined with
CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a
way to get the LSM enabled, skipped, etc. But it was highly CONFIG
dependent.

SELinux does:

#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
...
        if (!security_module_enable("selinux")) {
                selinux_enabled = 0;
                return 0;
        }

        if (!selinux_enabled) {
                pr_info("SELinux:  Disabled at boot.\n");
                return 0;
        }


AppArmor does:

/* Boot time disable flag */
static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);

static int __init apparmor_enabled_setup(char *str)
{
        unsigned long enabled;
        int error = kstrtoul(str, 0, &enabled);
        if (!error)
                apparmor_enabled = enabled ? 1 : 0;
        return 1;
}

__setup("apparmor=", apparmor_enabled_setup);
...
        if (!apparmor_enabled || !security_module_enable("apparmor")) {
                aa_info_message("AppArmor disabled by boot time parameter");
                apparmor_enabled = false;
                return 0;
        }


Smack and TOMOYO each do:

        if (!security_module_enable("smack"))
                return 0;

        if (!security_module_enable("tomoyo"))
                return 0;


Capability, Integrity, Yama, and LoadPin always run init. (This series
fixes LoadPin to separate enable vs enforce, so we can ignore its
"enable" setting, which isn't an "am I active?" boolean -- its init
was always run.) With the enable logic is lifted out of the LSMs, we
want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I
had originally suggested CONFIG_LSM_DISABLE, since the normal state is
enabled.) But given your feedback, I made this "implicit disable" and
added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all"
gets the same results.)


I think, then, the first question (mainly for you and Paul) is:

Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only
CONFIG_LSM_ENABLE?

The answer will affect the next question: what should be done with the
boot parameters? AppArmor has two ways to change enablement:
apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1.
Should those be removed in favor of "lsm.enable=..."? (And if they're
not removed, how do people imagine they should interact?)

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 22:27     ` Kees Cook
@ 2018-10-01 22:27       ` Kees Cook
  2018-10-01 22:48       ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 22:27 UTC (permalink / raw)
  To: John Johansen, Paul Moore
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 09/24/2018 05:18 PM, Kees Cook wrote:
>> 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>
>
> I don't like this. It brings about conflicting kernel params that are
> bound to confuse users. Its pretty easy for a user to understand that
> when they specify a parameter manually at boot, that  it overrides the
> build time default. But conflicting kernel parameters are a lot harder
> to deal with.
>
> I prefer a plain enabled= list being an override of the default build
> time value. Where conflicts with LSM-specific configs always result in
> the LSM being disabled with a complaint about the conflict.
>
> Though I have yet to be convinced its worth the cost, I do recognize
> it is sometimes convenient to disable a single LSM, instead of typing
> in a whole list of what to enable. If we have to have conflicting
> kernel parameters I would prefer that the conflict throw up a warning
> and leaving the LSM with the conflicting config disabled.

Alright, let's drill down a bit more. I thought I had all the
requirements sorted out here. :)

AppArmor and SELinux are "special" here in that they have both:

- CONFIG for enable-ness
- boot param for enable-ness

Now, the way this worked in the past was that combined with
CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a
way to get the LSM enabled, skipped, etc. But it was highly CONFIG
dependent.

SELinux does:

#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
...
        if (!security_module_enable("selinux")) {
                selinux_enabled = 0;
                return 0;
        }

        if (!selinux_enabled) {
                pr_info("SELinux:  Disabled at boot.\n");
                return 0;
        }


AppArmor does:

/* Boot time disable flag */
static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);

static int __init apparmor_enabled_setup(char *str)
{
        unsigned long enabled;
        int error = kstrtoul(str, 0, &enabled);
        if (!error)
                apparmor_enabled = enabled ? 1 : 0;
        return 1;
}

__setup("apparmor=", apparmor_enabled_setup);
...
        if (!apparmor_enabled || !security_module_enable("apparmor")) {
                aa_info_message("AppArmor disabled by boot time parameter");
                apparmor_enabled = false;
                return 0;
        }


Smack and TOMOYO each do:

        if (!security_module_enable("smack"))
                return 0;

        if (!security_module_enable("tomoyo"))
                return 0;


Capability, Integrity, Yama, and LoadPin always run init. (This series
fixes LoadPin to separate enable vs enforce, so we can ignore its
"enable" setting, which isn't an "am I active?" boolean -- its init
was always run.) With the enable logic is lifted out of the LSMs, we
want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I
had originally suggested CONFIG_LSM_DISABLE, since the normal state is
enabled.) But given your feedback, I made this "implicit disable" and
added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all"
gets the same results.)


I think, then, the first question (mainly for you and Paul) is:

Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only
CONFIG_LSM_ENABLE?

The answer will affect the next question: what should be done with the
boot parameters? AppArmor has two ways to change enablement:
apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1.
Should those be removed in favor of "lsm.enable=..."? (And if they're
not removed, how do people imagine they should interact?)

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-10-01 22:20       ` John Johansen
  2018-10-01 22:20         ` John Johansen
@ 2018-10-01 22:29         ` Kees Cook
  2018-10-01 22:29           ` Kees Cook
  2018-10-01 22:53           ` John Johansen
  1 sibling, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 22:29 UTC (permalink / raw)
  To: John Johansen
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 3:20 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/01/2018 02:56 PM, Kees Cook wrote:
>> On Mon, Oct 1, 2018 at 2:47 PM, James Morris <jmorris@namei.org> wrote:
>>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>>
>>>> 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>
>>>> ---
>>>>  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 5056f7374b3d..2a41e8e6f6e5 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;       /* Populated automatically. */
>>>>       unsigned long flags;    /* Optional: flags describing LSM */
>>>> +     int *enabled;           /* Optional: NULL means enabled. */
>>>
>>> This seems potentially confusing.
>>>
>>> Perhaps initialize 'enabled' to a default int pointer, like:
>>>
>>>         static int lsm_default_enabled = 1;
>>>
>>> Then,
>>>
>>>         DEFINE_LSM(foobar)
>>>         flags = LSM_FLAG_LEGACY_MAJOR,
>>>         .enabled = &lsm_default_enabled,
>>>         .init = foobar_init,
>>>         END_LSM;
>>
>> The reason I didn't do this is because there are only two LSMs that
>> expose this "enabled" variable, so I didn't like making the other LSMs
>> have to declare this. Internally, though, this is exactly what the
>> infrastructure does: if it finds a NULL, it aims it at
>> &lsm_default_enabled (in a later patch).
>>
>> However, it seems more discussion is needed on the "enable" bit of
>> this, so I'll reply to John in a moment...
>>
> fwiw the apparmor.enabled config is really only a meant to be used to
> disable apparmor. I'd drop it entirely except its part of the userspace
> api now and needs to show up in
>
>   /sys/module/apparmor/parameters/enabled

Showing the enabled-ness there can be wired up. What should happen if
someone sets apparmor.enabled=0/1 in new-series-world? (See other
thread...)

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-10-01 22:29         ` Kees Cook
@ 2018-10-01 22:29           ` Kees Cook
  2018-10-01 22:53           ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 22:29 UTC (permalink / raw)
  To: John Johansen
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 3:20 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/01/2018 02:56 PM, Kees Cook wrote:
>> On Mon, Oct 1, 2018 at 2:47 PM, James Morris <jmorris@namei.org> wrote:
>>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>>
>>>> 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>
>>>> ---
>>>>  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 5056f7374b3d..2a41e8e6f6e5 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;       /* Populated automatically. */
>>>>       unsigned long flags;    /* Optional: flags describing LSM */
>>>> +     int *enabled;           /* Optional: NULL means enabled. */
>>>
>>> This seems potentially confusing.
>>>
>>> Perhaps initialize 'enabled' to a default int pointer, like:
>>>
>>>         static int lsm_default_enabled = 1;
>>>
>>> Then,
>>>
>>>         DEFINE_LSM(foobar)
>>>         flags = LSM_FLAG_LEGACY_MAJOR,
>>>         .enabled = &lsm_default_enabled,
>>>         .init = foobar_init,
>>>         END_LSM;
>>
>> The reason I didn't do this is because there are only two LSMs that
>> expose this "enabled" variable, so I didn't like making the other LSMs
>> have to declare this. Internally, though, this is exactly what the
>> infrastructure does: if it finds a NULL, it aims it at
>> &lsm_default_enabled (in a later patch).
>>
>> However, it seems more discussion is needed on the "enable" bit of
>> this, so I'll reply to John in a moment...
>>
> fwiw the apparmor.enabled config is really only a meant to be used to
> disable apparmor. I'd drop it entirely except its part of the userspace
> api now and needs to show up in
>
>   /sys/module/apparmor/parameters/enabled

Showing the enabled-ness there can be wired up. What should happen if
someone sets apparmor.enabled=0/1 in new-series-world? (See other
thread...)

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-10-01 21:23     ` Steven Rostedt
  2018-10-01 21:23       ` Steven Rostedt
@ 2018-10-01 22:38       ` Kees Cook
  2018-10-01 22:38         ` Kees Cook
  1 sibling, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-10-01 22:38 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: John Johansen, James Morris, Serge E. Hallyn,
	Abderrahmane Benbachir, linux-security-module, Casey Schaufler,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 2:23 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 1 Oct 2018 14:07:55 -0700
> John Johansen <john.johansen@canonical.com> wrote:
>
>> On 09/24/2018 05:18 PM, 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.
>> >
>> > Cc: James Morris <jmorris@namei.org>
>> > Cc: "Serge E. Hallyn" <serge@hallyn.com>
>> > Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
>> > Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
>> > Cc: linux-security-module@vger.kernel.org
>> > Signed-off-by: Kees Cook <keescook@chromium.org>
>>
>>
>> Reviewed-by: John Johansen <john.johansen@canonical.com>
>>
>> though I do think it would be a good idea to add a new set
>> of trace points, but that can come as a separate patch
>>
>>
>
> Agreed.

BTW, how would this look? I'm not familiar with adding new tracepoints...

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 04/29] LSM: Remove initcall tracing
  2018-10-01 22:38       ` Kees Cook
@ 2018-10-01 22:38         ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 22:38 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: John Johansen, James Morris, Serge E. Hallyn,
	Abderrahmane Benbachir, linux-security-module, Casey Schaufler,
	Tetsuo Handa, Paul Moore, Stephen Smalley, Schaufler, Casey,
	Jonathan Corbet, open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 2:23 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 1 Oct 2018 14:07:55 -0700
> John Johansen <john.johansen@canonical.com> wrote:
>
>> On 09/24/2018 05:18 PM, 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.
>> >
>> > Cc: James Morris <jmorris@namei.org>
>> > Cc: "Serge E. Hallyn" <serge@hallyn.com>
>> > Cc: Abderrahmane Benbachir <abderrahmane.benbachir@polymtl.ca>
>> > Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
>> > Cc: linux-security-module@vger.kernel.org
>> > Signed-off-by: Kees Cook <keescook@chromium.org>
>>
>>
>> Reviewed-by: John Johansen <john.johansen@canonical.com>
>>
>> though I do think it would be a good idea to add a new set
>> of trace points, but that can come as a separate patch
>>
>>
>
> Agreed.

BTW, how would this look? I'm not familiar with adding new tracepoints...

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 22:27     ` Kees Cook
  2018-10-01 22:27       ` Kees Cook
@ 2018-10-01 22:48       ` John Johansen
  2018-10-01 22:48         ` John Johansen
  2018-10-01 23:30         ` Kees Cook
  1 sibling, 2 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 22:48 UTC (permalink / raw)
  To: Kees Cook, Paul Moore
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/01/2018 03:27 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>>> 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>
>>
>> I don't like this. It brings about conflicting kernel params that are
>> bound to confuse users. Its pretty easy for a user to understand that
>> when they specify a parameter manually at boot, that  it overrides the
>> build time default. But conflicting kernel parameters are a lot harder
>> to deal with.
>>
>> I prefer a plain enabled= list being an override of the default build
>> time value. Where conflicts with LSM-specific configs always result in
>> the LSM being disabled with a complaint about the conflict.
>>
>> Though I have yet to be convinced its worth the cost, I do recognize
>> it is sometimes convenient to disable a single LSM, instead of typing
>> in a whole list of what to enable. If we have to have conflicting
>> kernel parameters I would prefer that the conflict throw up a warning
>> and leaving the LSM with the conflicting config disabled.
> 
> Alright, let's drill down a bit more. I thought I had all the
> requirements sorted out here. :)
> 
> AppArmor and SELinux are "special" here in that they have both:
> 
> - CONFIG for enable-ness
> - boot param for enable-ness
> 
> Now, the way this worked in the past was that combined with
> CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a
> way to get the LSM enabled, skipped, etc. But it was highly CONFIG
> dependent.
> 
> SELinux does:
> 
> #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
> ...
>         if (!security_module_enable("selinux")) {
>                 selinux_enabled = 0;
>                 return 0;
>         }
> 
>         if (!selinux_enabled) {
>                 pr_info("SELinux:  Disabled at boot.\n");
>                 return 0;
>         }
> 
> 
> AppArmor does:
> 
> /* Boot time disable flag */
> static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
> module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
> 
> static int __init apparmor_enabled_setup(char *str)
> {
>         unsigned long enabled;
>         int error = kstrtoul(str, 0, &enabled);
>         if (!error)
>                 apparmor_enabled = enabled ? 1 : 0;
>         return 1;
> }
> 
> __setup("apparmor=", apparmor_enabled_setup);
> ...
>         if (!apparmor_enabled || !security_module_enable("apparmor")) {
>                 aa_info_message("AppArmor disabled by boot time parameter");
>                 apparmor_enabled = false;
>                 return 0;
>         }
> 
> 
> Smack and TOMOYO each do:
> 
>         if (!security_module_enable("smack"))
>                 return 0;
> 
>         if (!security_module_enable("tomoyo"))
>                 return 0;
> 
> 
> Capability, Integrity, Yama, and LoadPin always run init. (This series
> fixes LoadPin to separate enable vs enforce, so we can ignore its
> "enable" setting, which isn't an "am I active?" boolean -- its init
> was always run.) With the enable logic is lifted out of the LSMs, we
> want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I
> had originally suggested CONFIG_LSM_DISABLE, since the normal state is
> enabled.) But given your feedback, I made this "implicit disable" and
> added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all"
> gets the same results.)
> 
> 
> I think, then, the first question (mainly for you and Paul) is:
> 
> Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and
> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only
> CONFIG_LSM_ENABLE?
> 

We can remove the Kconfig for the apparmor bootparam value. In fact I
will attach that patch below. I can't get rid of the parameter as it
is part of the userspace api. There are tools and applications
checking /sys/module/apparmor/parameters/enabled

but we can certainly default it to enabled and make it work only as a
runtime kernel parameter to disable apparmor which is how it has been
traditionally been used.

> The answer will affect the next question: what should be done with the
> boot parameters? AppArmor has two ways to change enablement:
> apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1.
> Should those be removed in favor of "lsm.enable=..."? (And if they're
> not removed, how do people imagine they should interact?)
> 

I am not against removing the apparmor one, it does mean retraining
users but it is seldmon used so it may be worth dropping. If we keep
it, it should be a disable only flag that where the use of apparmor=0
or apparmor.enable=0 (same thing) means apparmor is disabled.

---

commit 367b8a47105c68fa170bdd14b0204555eb930476
Author: John Johansen <john.johansen@canonical.com>
Date:   Mon Oct 1 15:46:02 2018 -0700

    apparmor: remove apparmor boot param config
    
    The boot param value is only ever used as a means to disable apparmor.
    Get rid of the Kconfig and a default the parameter to true.
    
    Signed-off-by: John Johansen <john.johansen@canonical.com>

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 f09fea0b4db7..8e83ee52a0a3 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1303,7 +1303,7 @@ 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;
+static bool apparmor_enabled = true;
 module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
 
 static int __init apparmor_enabled_setup(char *str)

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 22:48       ` John Johansen
@ 2018-10-01 22:48         ` John Johansen
  2018-10-01 23:30         ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 22:48 UTC (permalink / raw)
  To: Kees Cook, Paul Moore
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Stephen Smalley,
	Schaufler, Casey, LSM, Jonathan Corbet, open list:DOCUMENTATION,
	linux-arch, LKML

On 10/01/2018 03:27 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>>> 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>
>>
>> I don't like this. It brings about conflicting kernel params that are
>> bound to confuse users. Its pretty easy for a user to understand that
>> when they specify a parameter manually at boot, that  it overrides the
>> build time default. But conflicting kernel parameters are a lot harder
>> to deal with.
>>
>> I prefer a plain enabled= list being an override of the default build
>> time value. Where conflicts with LSM-specific configs always result in
>> the LSM being disabled with a complaint about the conflict.
>>
>> Though I have yet to be convinced its worth the cost, I do recognize
>> it is sometimes convenient to disable a single LSM, instead of typing
>> in a whole list of what to enable. If we have to have conflicting
>> kernel parameters I would prefer that the conflict throw up a warning
>> and leaving the LSM with the conflicting config disabled.
> 
> Alright, let's drill down a bit more. I thought I had all the
> requirements sorted out here. :)
> 
> AppArmor and SELinux are "special" here in that they have both:
> 
> - CONFIG for enable-ness
> - boot param for enable-ness
> 
> Now, the way this worked in the past was that combined with
> CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a
> way to get the LSM enabled, skipped, etc. But it was highly CONFIG
> dependent.
> 
> SELinux does:
> 
> #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
> ...
>         if (!security_module_enable("selinux")) {
>                 selinux_enabled = 0;
>                 return 0;
>         }
> 
>         if (!selinux_enabled) {
>                 pr_info("SELinux:  Disabled at boot.\n");
>                 return 0;
>         }
> 
> 
> AppArmor does:
> 
> /* Boot time disable flag */
> static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
> module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
> 
> static int __init apparmor_enabled_setup(char *str)
> {
>         unsigned long enabled;
>         int error = kstrtoul(str, 0, &enabled);
>         if (!error)
>                 apparmor_enabled = enabled ? 1 : 0;
>         return 1;
> }
> 
> __setup("apparmor=", apparmor_enabled_setup);
> ...
>         if (!apparmor_enabled || !security_module_enable("apparmor")) {
>                 aa_info_message("AppArmor disabled by boot time parameter");
>                 apparmor_enabled = false;
>                 return 0;
>         }
> 
> 
> Smack and TOMOYO each do:
> 
>         if (!security_module_enable("smack"))
>                 return 0;
> 
>         if (!security_module_enable("tomoyo"))
>                 return 0;
> 
> 
> Capability, Integrity, Yama, and LoadPin always run init. (This series
> fixes LoadPin to separate enable vs enforce, so we can ignore its
> "enable" setting, which isn't an "am I active?" boolean -- its init
> was always run.) With the enable logic is lifted out of the LSMs, we
> want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I
> had originally suggested CONFIG_LSM_DISABLE, since the normal state is
> enabled.) But given your feedback, I made this "implicit disable" and
> added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all"
> gets the same results.)
> 
> 
> I think, then, the first question (mainly for you and Paul) is:
> 
> Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and
> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only
> CONFIG_LSM_ENABLE?
> 

We can remove the Kconfig for the apparmor bootparam value. In fact I
will attach that patch below. I can't get rid of the parameter as it
is part of the userspace api. There are tools and applications
checking /sys/module/apparmor/parameters/enabled

but we can certainly default it to enabled and make it work only as a
runtime kernel parameter to disable apparmor which is how it has been
traditionally been used.

> The answer will affect the next question: what should be done with the
> boot parameters? AppArmor has two ways to change enablement:
> apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1.
> Should those be removed in favor of "lsm.enable=..."? (And if they're
> not removed, how do people imagine they should interact?)
> 

I am not against removing the apparmor one, it does mean retraining
users but it is seldmon used so it may be worth dropping. If we keep
it, it should be a disable only flag that where the use of apparmor=0
or apparmor.enable=0 (same thing) means apparmor is disabled.

---

commit 367b8a47105c68fa170bdd14b0204555eb930476
Author: John Johansen <john.johansen@canonical.com>
Date:   Mon Oct 1 15:46:02 2018 -0700

    apparmor: remove apparmor boot param config
    
    The boot param value is only ever used as a means to disable apparmor.
    Get rid of the Kconfig and a default the parameter to true.
    
    Signed-off-by: John Johansen <john.johansen@canonical.com>

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 f09fea0b4db7..8e83ee52a0a3 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1303,7 +1303,7 @@ 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;
+static bool apparmor_enabled = true;
 module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
 
 static int __init apparmor_enabled_setup(char *str)

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-10-01 22:29         ` Kees Cook
  2018-10-01 22:29           ` Kees Cook
@ 2018-10-01 22:53           ` John Johansen
  2018-10-01 22:53             ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 22:53 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On 10/01/2018 03:29 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 3:20 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/01/2018 02:56 PM, Kees Cook wrote:
>>> On Mon, Oct 1, 2018 at 2:47 PM, James Morris <jmorris@namei.org> wrote:
>>>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>>>
>>>>> 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>
>>>>> ---
>>>>>  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 5056f7374b3d..2a41e8e6f6e5 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;       /* Populated automatically. */
>>>>>       unsigned long flags;    /* Optional: flags describing LSM */
>>>>> +     int *enabled;           /* Optional: NULL means enabled. */
>>>>
>>>> This seems potentially confusing.
>>>>
>>>> Perhaps initialize 'enabled' to a default int pointer, like:
>>>>
>>>>         static int lsm_default_enabled = 1;
>>>>
>>>> Then,
>>>>
>>>>         DEFINE_LSM(foobar)
>>>>         flags = LSM_FLAG_LEGACY_MAJOR,
>>>>         .enabled = &lsm_default_enabled,
>>>>         .init = foobar_init,
>>>>         END_LSM;
>>>
>>> The reason I didn't do this is because there are only two LSMs that
>>> expose this "enabled" variable, so I didn't like making the other LSMs
>>> have to declare this. Internally, though, this is exactly what the
>>> infrastructure does: if it finds a NULL, it aims it at
>>> &lsm_default_enabled (in a later patch).
>>>
>>> However, it seems more discussion is needed on the "enable" bit of
>>> this, so I'll reply to John in a moment...
>>>
>> fwiw the apparmor.enabled config is really only a meant to be used to
>> disable apparmor. I'd drop it entirely except its part of the userspace
>> api now and needs to show up in
>>
>>   /sys/module/apparmor/parameters/enabled
> 
> Showing the enabled-ness there can be wired up. What should happen if
> someone sets apparmor.enabled=0/1 in new-series-world? (See other
> thread...)
> 
I am open to either just making apparmor=0/apparmor.enabled=0 a means
of only disabling apparmor, thats how it is currently used. Or even
potentially getting rid of it as an available kernel boot config
parameter and running with just lsm.enabled/disabled.

The important bit that applications are relying on is having
  /sys/module/apparmor/parameters/enabled

set to the the correct value.

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

* Re: [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state
  2018-10-01 22:53           ` John Johansen
@ 2018-10-01 22:53             ` John Johansen
  0 siblings, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 22:53 UTC (permalink / raw)
  To: Kees Cook
  Cc: James Morris, Casey Schaufler, Tetsuo Handa, Paul Moore,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On 10/01/2018 03:29 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 3:20 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/01/2018 02:56 PM, Kees Cook wrote:
>>> On Mon, Oct 1, 2018 at 2:47 PM, James Morris <jmorris@namei.org> wrote:
>>>> On Mon, 24 Sep 2018, Kees Cook wrote:
>>>>
>>>>> 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>
>>>>> ---
>>>>>  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 5056f7374b3d..2a41e8e6f6e5 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;       /* Populated automatically. */
>>>>>       unsigned long flags;    /* Optional: flags describing LSM */
>>>>> +     int *enabled;           /* Optional: NULL means enabled. */
>>>>
>>>> This seems potentially confusing.
>>>>
>>>> Perhaps initialize 'enabled' to a default int pointer, like:
>>>>
>>>>         static int lsm_default_enabled = 1;
>>>>
>>>> Then,
>>>>
>>>>         DEFINE_LSM(foobar)
>>>>         flags = LSM_FLAG_LEGACY_MAJOR,
>>>>         .enabled = &lsm_default_enabled,
>>>>         .init = foobar_init,
>>>>         END_LSM;
>>>
>>> The reason I didn't do this is because there are only two LSMs that
>>> expose this "enabled" variable, so I didn't like making the other LSMs
>>> have to declare this. Internally, though, this is exactly what the
>>> infrastructure does: if it finds a NULL, it aims it at
>>> &lsm_default_enabled (in a later patch).
>>>
>>> However, it seems more discussion is needed on the "enable" bit of
>>> this, so I'll reply to John in a moment...
>>>
>> fwiw the apparmor.enabled config is really only a meant to be used to
>> disable apparmor. I'd drop it entirely except its part of the userspace
>> api now and needs to show up in
>>
>>   /sys/module/apparmor/parameters/enabled
> 
> Showing the enabled-ness there can be wired up. What should happen if
> someone sets apparmor.enabled=0/1 in new-series-world? (See other
> thread...)
> 
I am open to either just making apparmor=0/apparmor.enabled=0 a means
of only disabling apparmor, thats how it is currently used. Or even
potentially getting rid of it as an available kernel boot config
parameter and running with just lsm.enabled/disabled.

The important bit that applications are relying on is having
  /sys/module/apparmor/parameters/enabled

set to the the correct value.

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 22:48       ` John Johansen
  2018-10-01 22:48         ` John Johansen
@ 2018-10-01 23:30         ` Kees Cook
  2018-10-01 23:30           ` Kees Cook
                             ` (2 more replies)
  1 sibling, 3 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 23:30 UTC (permalink / raw)
  To: John Johansen
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 3:48 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/01/2018 03:27 PM, Kees Cook wrote:
>> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>>>> 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>
>>>
>>> I don't like this. It brings about conflicting kernel params that are
>>> bound to confuse users. Its pretty easy for a user to understand that
>>> when they specify a parameter manually at boot, that  it overrides the
>>> build time default. But conflicting kernel parameters are a lot harder
>>> to deal with.
>>>
>>> I prefer a plain enabled= list being an override of the default build
>>> time value. Where conflicts with LSM-specific configs always result in
>>> the LSM being disabled with a complaint about the conflict.
>>>
>>> Though I have yet to be convinced its worth the cost, I do recognize
>>> it is sometimes convenient to disable a single LSM, instead of typing
>>> in a whole list of what to enable. If we have to have conflicting
>>> kernel parameters I would prefer that the conflict throw up a warning
>>> and leaving the LSM with the conflicting config disabled.
>>
>> Alright, let's drill down a bit more. I thought I had all the
>> requirements sorted out here. :)
>>
>> AppArmor and SELinux are "special" here in that they have both:
>>
>> - CONFIG for enable-ness
>> - boot param for enable-ness
>>
>> Now, the way this worked in the past was that combined with
>> CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a
>> way to get the LSM enabled, skipped, etc. But it was highly CONFIG
>> dependent.
>>
>> SELinux does:
>>
>> #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
>> ...
>>         if (!security_module_enable("selinux")) {
>>                 selinux_enabled = 0;
>>                 return 0;
>>         }
>>
>>         if (!selinux_enabled) {
>>                 pr_info("SELinux:  Disabled at boot.\n");
>>                 return 0;
>>         }
>>
>>
>> AppArmor does:
>>
>> /* Boot time disable flag */
>> static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
>> module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
>>
>> static int __init apparmor_enabled_setup(char *str)
>> {
>>         unsigned long enabled;
>>         int error = kstrtoul(str, 0, &enabled);
>>         if (!error)
>>                 apparmor_enabled = enabled ? 1 : 0;
>>         return 1;
>> }
>>
>> __setup("apparmor=", apparmor_enabled_setup);
>> ...
>>         if (!apparmor_enabled || !security_module_enable("apparmor")) {
>>                 aa_info_message("AppArmor disabled by boot time parameter");
>>                 apparmor_enabled = false;
>>                 return 0;
>>         }
>>
>>
>> Smack and TOMOYO each do:
>>
>>         if (!security_module_enable("smack"))
>>                 return 0;
>>
>>         if (!security_module_enable("tomoyo"))
>>                 return 0;
>>
>>
>> Capability, Integrity, Yama, and LoadPin always run init. (This series
>> fixes LoadPin to separate enable vs enforce, so we can ignore its
>> "enable" setting, which isn't an "am I active?" boolean -- its init
>> was always run.) With the enable logic is lifted out of the LSMs, we
>> want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I
>> had originally suggested CONFIG_LSM_DISABLE, since the normal state is
>> enabled.) But given your feedback, I made this "implicit disable" and
>> added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all"
>> gets the same results.)
>>
>>
>> I think, then, the first question (mainly for you and Paul) is:
>>
>> Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and
>> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only
>> CONFIG_LSM_ENABLE?
>>
>
> We can remove the Kconfig for the apparmor bootparam value. In fact I
> will attach that patch below. I can't get rid of the parameter as it
> is part of the userspace api. There are tools and applications
> checking /sys/module/apparmor/parameters/enabled
>
> but we can certainly default it to enabled and make it work only as a
> runtime kernel parameter to disable apparmor which is how it has been
> traditionally been used.
>
>> The answer will affect the next question: what should be done with the
>> boot parameters? AppArmor has two ways to change enablement:
>> apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1.
>> Should those be removed in favor of "lsm.enable=..."? (And if they're
>> not removed, how do people imagine they should interact?)
>
> I am not against removing the apparmor one, it does mean retraining
> users but it is seldmon used so it may be worth dropping. If we keep
> it, it should be a disable only flag that where the use of apparmor=0
> or apparmor.enable=0 (same thing) means apparmor is disabled.

If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
enabled. Is that okay?

> ---
>
> commit 367b8a47105c68fa170bdd14b0204555eb930476
> Author: John Johansen <john.johansen@canonical.com>
> Date:   Mon Oct 1 15:46:02 2018 -0700
>
>     apparmor: remove apparmor boot param config
>
>     The boot param value is only ever used as a means to disable apparmor.
>     Get rid of the Kconfig and a default the parameter to true.
>
>     Signed-off-by: John Johansen <john.johansen@canonical.com>
>
> 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 f09fea0b4db7..8e83ee52a0a3 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1303,7 +1303,7 @@ 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;
> +static bool apparmor_enabled = true;

In the new world, this wouldn't be "= true" since its state would be
controlled by CONFIG_LSM_ENABLE (and lsm.enable=...). Is that okay?

>  module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
>
>  static int __init apparmor_enabled_setup(char *str)

I'll add this to the series, thanks!

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 23:30         ` Kees Cook
@ 2018-10-01 23:30           ` Kees Cook
  2018-10-01 23:38           ` Kees Cook
  2018-10-01 23:44           ` John Johansen
  2 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 23:30 UTC (permalink / raw)
  To: John Johansen
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 3:48 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/01/2018 03:27 PM, Kees Cook wrote:
>> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>>>> 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>
>>>
>>> I don't like this. It brings about conflicting kernel params that are
>>> bound to confuse users. Its pretty easy for a user to understand that
>>> when they specify a parameter manually at boot, that  it overrides the
>>> build time default. But conflicting kernel parameters are a lot harder
>>> to deal with.
>>>
>>> I prefer a plain enabled= list being an override of the default build
>>> time value. Where conflicts with LSM-specific configs always result in
>>> the LSM being disabled with a complaint about the conflict.
>>>
>>> Though I have yet to be convinced its worth the cost, I do recognize
>>> it is sometimes convenient to disable a single LSM, instead of typing
>>> in a whole list of what to enable. If we have to have conflicting
>>> kernel parameters I would prefer that the conflict throw up a warning
>>> and leaving the LSM with the conflicting config disabled.
>>
>> Alright, let's drill down a bit more. I thought I had all the
>> requirements sorted out here. :)
>>
>> AppArmor and SELinux are "special" here in that they have both:
>>
>> - CONFIG for enable-ness
>> - boot param for enable-ness
>>
>> Now, the way this worked in the past was that combined with
>> CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a
>> way to get the LSM enabled, skipped, etc. But it was highly CONFIG
>> dependent.
>>
>> SELinux does:
>>
>> #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
>> ...
>>         if (!security_module_enable("selinux")) {
>>                 selinux_enabled = 0;
>>                 return 0;
>>         }
>>
>>         if (!selinux_enabled) {
>>                 pr_info("SELinux:  Disabled at boot.\n");
>>                 return 0;
>>         }
>>
>>
>> AppArmor does:
>>
>> /* Boot time disable flag */
>> static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
>> module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
>>
>> static int __init apparmor_enabled_setup(char *str)
>> {
>>         unsigned long enabled;
>>         int error = kstrtoul(str, 0, &enabled);
>>         if (!error)
>>                 apparmor_enabled = enabled ? 1 : 0;
>>         return 1;
>> }
>>
>> __setup("apparmor=", apparmor_enabled_setup);
>> ...
>>         if (!apparmor_enabled || !security_module_enable("apparmor")) {
>>                 aa_info_message("AppArmor disabled by boot time parameter");
>>                 apparmor_enabled = false;
>>                 return 0;
>>         }
>>
>>
>> Smack and TOMOYO each do:
>>
>>         if (!security_module_enable("smack"))
>>                 return 0;
>>
>>         if (!security_module_enable("tomoyo"))
>>                 return 0;
>>
>>
>> Capability, Integrity, Yama, and LoadPin always run init. (This series
>> fixes LoadPin to separate enable vs enforce, so we can ignore its
>> "enable" setting, which isn't an "am I active?" boolean -- its init
>> was always run.) With the enable logic is lifted out of the LSMs, we
>> want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I
>> had originally suggested CONFIG_LSM_DISABLE, since the normal state is
>> enabled.) But given your feedback, I made this "implicit disable" and
>> added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all"
>> gets the same results.)
>>
>>
>> I think, then, the first question (mainly for you and Paul) is:
>>
>> Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and
>> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only
>> CONFIG_LSM_ENABLE?
>>
>
> We can remove the Kconfig for the apparmor bootparam value. In fact I
> will attach that patch below. I can't get rid of the parameter as it
> is part of the userspace api. There are tools and applications
> checking /sys/module/apparmor/parameters/enabled
>
> but we can certainly default it to enabled and make it work only as a
> runtime kernel parameter to disable apparmor which is how it has been
> traditionally been used.
>
>> The answer will affect the next question: what should be done with the
>> boot parameters? AppArmor has two ways to change enablement:
>> apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1.
>> Should those be removed in favor of "lsm.enable=..."? (And if they're
>> not removed, how do people imagine they should interact?)
>
> I am not against removing the apparmor one, it does mean retraining
> users but it is seldmon used so it may be worth dropping. If we keep
> it, it should be a disable only flag that where the use of apparmor=0
> or apparmor.enable=0 (same thing) means apparmor is disabled.

If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
enabled. Is that okay?

> ---
>
> commit 367b8a47105c68fa170bdd14b0204555eb930476
> Author: John Johansen <john.johansen@canonical.com>
> Date:   Mon Oct 1 15:46:02 2018 -0700
>
>     apparmor: remove apparmor boot param config
>
>     The boot param value is only ever used as a means to disable apparmor.
>     Get rid of the Kconfig and a default the parameter to true.
>
>     Signed-off-by: John Johansen <john.johansen@canonical.com>
>
> 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 f09fea0b4db7..8e83ee52a0a3 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -1303,7 +1303,7 @@ 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;
> +static bool apparmor_enabled = true;

In the new world, this wouldn't be "= true" since its state would be
controlled by CONFIG_LSM_ENABLE (and lsm.enable=...). Is that okay?

>  module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
>
>  static int __init apparmor_enabled_setup(char *str)

I'll add this to the series, thanks!

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 23:30         ` Kees Cook
  2018-10-01 23:30           ` Kees Cook
@ 2018-10-01 23:38           ` Kees Cook
  2018-10-01 23:38             ` Kees Cook
  2018-10-01 23:57             ` John Johansen
  2018-10-01 23:44           ` John Johansen
  2 siblings, 2 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 23:38 UTC (permalink / raw)
  To: John Johansen
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 4:30 PM, Kees Cook <keescook@chromium.org> wrote:
> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
> enabled. Is that okay?

Actually, what the v3 series does right now is leaves AppArmor and
SELinux alone -- whatever they configured for enable/disable is left
alone.

The problem I have is when processing CONFIG_LSM_ENABLE ... what do I
do with the existing "enable" flag? It's set by both
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE and apparmor=0/1.

Right now I can't tell the difference between someone booting with
apparmor=0 or CONFIG_LSM_ENABLE not including apparmor.

i.e. how do I mix CONFIG_LSM_ENABLE with apparmor=0/1? (assuming
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE has been removed)

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 23:38           ` Kees Cook
@ 2018-10-01 23:38             ` Kees Cook
  2018-10-01 23:57             ` John Johansen
  1 sibling, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 23:38 UTC (permalink / raw)
  To: John Johansen
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 4:30 PM, Kees Cook <keescook@chromium.org> wrote:
> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
> enabled. Is that okay?

Actually, what the v3 series does right now is leaves AppArmor and
SELinux alone -- whatever they configured for enable/disable is left
alone.

The problem I have is when processing CONFIG_LSM_ENABLE ... what do I
do with the existing "enable" flag? It's set by both
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE and apparmor=0/1.

Right now I can't tell the difference between someone booting with
apparmor=0 or CONFIG_LSM_ENABLE not including apparmor.

i.e. how do I mix CONFIG_LSM_ENABLE with apparmor=0/1? (assuming
CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE has been removed)

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 23:30         ` Kees Cook
  2018-10-01 23:30           ` Kees Cook
  2018-10-01 23:38           ` Kees Cook
@ 2018-10-01 23:44           ` John Johansen
  2018-10-01 23:44             ` John Johansen
  2018-10-01 23:49             ` Kees Cook
  2 siblings, 2 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 23:44 UTC (permalink / raw)
  To: Kees Cook
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On 10/01/2018 04:30 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 3:48 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/01/2018 03:27 PM, Kees Cook wrote:
>>> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>>>>> 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>
>>>>
>>>> I don't like this. It brings about conflicting kernel params that are
>>>> bound to confuse users. Its pretty easy for a user to understand that
>>>> when they specify a parameter manually at boot, that  it overrides the
>>>> build time default. But conflicting kernel parameters are a lot harder
>>>> to deal with.
>>>>
>>>> I prefer a plain enabled= list being an override of the default build
>>>> time value. Where conflicts with LSM-specific configs always result in
>>>> the LSM being disabled with a complaint about the conflict.
>>>>
>>>> Though I have yet to be convinced its worth the cost, I do recognize
>>>> it is sometimes convenient to disable a single LSM, instead of typing
>>>> in a whole list of what to enable. If we have to have conflicting
>>>> kernel parameters I would prefer that the conflict throw up a warning
>>>> and leaving the LSM with the conflicting config disabled.
>>>
>>> Alright, let's drill down a bit more. I thought I had all the
>>> requirements sorted out here. :)
>>>
>>> AppArmor and SELinux are "special" here in that they have both:
>>>
>>> - CONFIG for enable-ness
>>> - boot param for enable-ness
>>>
>>> Now, the way this worked in the past was that combined with
>>> CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a
>>> way to get the LSM enabled, skipped, etc. But it was highly CONFIG
>>> dependent.
>>>
>>> SELinux does:
>>>
>>> #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
>>> ...
>>>         if (!security_module_enable("selinux")) {
>>>                 selinux_enabled = 0;
>>>                 return 0;
>>>         }
>>>
>>>         if (!selinux_enabled) {
>>>                 pr_info("SELinux:  Disabled at boot.\n");
>>>                 return 0;
>>>         }
>>>
>>>
>>> AppArmor does:
>>>
>>> /* Boot time disable flag */
>>> static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
>>> module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
>>>
>>> static int __init apparmor_enabled_setup(char *str)
>>> {
>>>         unsigned long enabled;
>>>         int error = kstrtoul(str, 0, &enabled);
>>>         if (!error)
>>>                 apparmor_enabled = enabled ? 1 : 0;
>>>         return 1;
>>> }
>>>
>>> __setup("apparmor=", apparmor_enabled_setup);
>>> ...
>>>         if (!apparmor_enabled || !security_module_enable("apparmor")) {
>>>                 aa_info_message("AppArmor disabled by boot time parameter");
>>>                 apparmor_enabled = false;
>>>                 return 0;
>>>         }
>>>
>>>
>>> Smack and TOMOYO each do:
>>>
>>>         if (!security_module_enable("smack"))
>>>                 return 0;
>>>
>>>         if (!security_module_enable("tomoyo"))
>>>                 return 0;
>>>
>>>
>>> Capability, Integrity, Yama, and LoadPin always run init. (This series
>>> fixes LoadPin to separate enable vs enforce, so we can ignore its
>>> "enable" setting, which isn't an "am I active?" boolean -- its init
>>> was always run.) With the enable logic is lifted out of the LSMs, we
>>> want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I
>>> had originally suggested CONFIG_LSM_DISABLE, since the normal state is
>>> enabled.) But given your feedback, I made this "implicit disable" and
>>> added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all"
>>> gets the same results.)
>>>
>>>
>>> I think, then, the first question (mainly for you and Paul) is:
>>>
>>> Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and
>>> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only
>>> CONFIG_LSM_ENABLE?
>>>
>>
>> We can remove the Kconfig for the apparmor bootparam value. In fact I
>> will attach that patch below. I can't get rid of the parameter as it
>> is part of the userspace api. There are tools and applications
>> checking /sys/module/apparmor/parameters/enabled
>>
>> but we can certainly default it to enabled and make it work only as a
>> runtime kernel parameter to disable apparmor which is how it has been
>> traditionally been used.
>>
>>> The answer will affect the next question: what should be done with the
>>> boot parameters? AppArmor has two ways to change enablement:
>>> apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1.
>>> Should those be removed in favor of "lsm.enable=..."? (And if they're
>>> not removed, how do people imagine they should interact?)
>>
>> I am not against removing the apparmor one, it does mean retraining
>> users but it is seldmon used so it may be worth dropping. If we keep
>> it, it should be a disable only flag that where the use of apparmor=0
>> or apparmor.enable=0 (same thing) means apparmor is disabled.
> 
> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
> enabled. Is that okay?
> 
ugh I would rather get rid of apparmor=0 or to emit a warning with apparmor
disabled, but if we have to live with it then yes I can live with last
option wins

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 23:44           ` John Johansen
@ 2018-10-01 23:44             ` John Johansen
  2018-10-01 23:49             ` Kees Cook
  1 sibling, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 23:44 UTC (permalink / raw)
  To: Kees Cook
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On 10/01/2018 04:30 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 3:48 PM, John Johansen
> <john.johansen@canonical.com> wrote:
>> On 10/01/2018 03:27 PM, Kees Cook wrote:
>>> On Mon, Oct 1, 2018 at 2:46 PM, John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>> On 09/24/2018 05:18 PM, Kees Cook wrote:
>>>>> 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>
>>>>
>>>> I don't like this. It brings about conflicting kernel params that are
>>>> bound to confuse users. Its pretty easy for a user to understand that
>>>> when they specify a parameter manually at boot, that  it overrides the
>>>> build time default. But conflicting kernel parameters are a lot harder
>>>> to deal with.
>>>>
>>>> I prefer a plain enabled= list being an override of the default build
>>>> time value. Where conflicts with LSM-specific configs always result in
>>>> the LSM being disabled with a complaint about the conflict.
>>>>
>>>> Though I have yet to be convinced its worth the cost, I do recognize
>>>> it is sometimes convenient to disable a single LSM, instead of typing
>>>> in a whole list of what to enable. If we have to have conflicting
>>>> kernel parameters I would prefer that the conflict throw up a warning
>>>> and leaving the LSM with the conflicting config disabled.
>>>
>>> Alright, let's drill down a bit more. I thought I had all the
>>> requirements sorted out here. :)
>>>
>>> AppArmor and SELinux are "special" here in that they have both:
>>>
>>> - CONFIG for enable-ness
>>> - boot param for enable-ness
>>>
>>> Now, the way this worked in the past was that combined with
>>> CONFIG_DEFAULT_SECURITY and the link-time ordering, this resulted in a
>>> way to get the LSM enabled, skipped, etc. But it was highly CONFIG
>>> dependent.
>>>
>>> SELinux does:
>>>
>>> #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
>>> ...
>>>         if (!security_module_enable("selinux")) {
>>>                 selinux_enabled = 0;
>>>                 return 0;
>>>         }
>>>
>>>         if (!selinux_enabled) {
>>>                 pr_info("SELinux:  Disabled at boot.\n");
>>>                 return 0;
>>>         }
>>>
>>>
>>> AppArmor does:
>>>
>>> /* Boot time disable flag */
>>> static bool apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
>>> module_param_named(enabled, apparmor_enabled, bool, S_IRUGO);
>>>
>>> static int __init apparmor_enabled_setup(char *str)
>>> {
>>>         unsigned long enabled;
>>>         int error = kstrtoul(str, 0, &enabled);
>>>         if (!error)
>>>                 apparmor_enabled = enabled ? 1 : 0;
>>>         return 1;
>>> }
>>>
>>> __setup("apparmor=", apparmor_enabled_setup);
>>> ...
>>>         if (!apparmor_enabled || !security_module_enable("apparmor")) {
>>>                 aa_info_message("AppArmor disabled by boot time parameter");
>>>                 apparmor_enabled = false;
>>>                 return 0;
>>>         }
>>>
>>>
>>> Smack and TOMOYO each do:
>>>
>>>         if (!security_module_enable("smack"))
>>>                 return 0;
>>>
>>>         if (!security_module_enable("tomoyo"))
>>>                 return 0;
>>>
>>>
>>> Capability, Integrity, Yama, and LoadPin always run init. (This series
>>> fixes LoadPin to separate enable vs enforce, so we can ignore its
>>> "enable" setting, which isn't an "am I active?" boolean -- its init
>>> was always run.) With the enable logic is lifted out of the LSMs, we
>>> want to have "implicit enable" for 6 of 8 of the LSMs. (Which is why I
>>> had originally suggested CONFIG_LSM_DISABLE, since the normal state is
>>> enabled.) But given your feedback, I made this "implicit disable" and
>>> added CONFIG_LSM_ENABLE instead. (For which "CONFIG_LSM_ENABLE=all"
>>> gets the same results.)
>>>
>>>
>>> I think, then, the first question (mainly for you and Paul) is:
>>>
>>> Should we remove CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE and
>>> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE in favor of only
>>> CONFIG_LSM_ENABLE?
>>>
>>
>> We can remove the Kconfig for the apparmor bootparam value. In fact I
>> will attach that patch below. I can't get rid of the parameter as it
>> is part of the userspace api. There are tools and applications
>> checking /sys/module/apparmor/parameters/enabled
>>
>> but we can certainly default it to enabled and make it work only as a
>> runtime kernel parameter to disable apparmor which is how it has been
>> traditionally been used.
>>
>>> The answer will affect the next question: what should be done with the
>>> boot parameters? AppArmor has two ways to change enablement:
>>> apparmor=0/1 and apparmor.enabled=0/1. SELinux just has selinux=0/1.
>>> Should those be removed in favor of "lsm.enable=..."? (And if they're
>>> not removed, how do people imagine they should interact?)
>>
>> I am not against removing the apparmor one, it does mean retraining
>> users but it is seldmon used so it may be worth dropping. If we keep
>> it, it should be a disable only flag that where the use of apparmor=0
>> or apparmor.enable=0 (same thing) means apparmor is disabled.
> 
> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
> enabled. Is that okay?
> 
ugh I would rather get rid of apparmor=0 or to emit a warning with apparmor
disabled, but if we have to live with it then yes I can live with last
option wins

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 23:44           ` John Johansen
  2018-10-01 23:44             ` John Johansen
@ 2018-10-01 23:49             ` Kees Cook
  2018-10-01 23:49               ` Kees Cook
  1 sibling, 1 reply; 164+ messages in thread
From: Kees Cook @ 2018-10-01 23:49 UTC (permalink / raw)
  To: John Johansen
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 4:44 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/01/2018 04:30 PM, Kees Cook wrote:
>> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
>> enabled. Is that okay?
>>
> ugh I would rather get rid of apparmor=0 or to emit a warning with apparmor
> disabled, but if we have to live with it then yes I can live with last
> option wins

Removing it would be much preferred! :)

Assuming Paul is okay with the same results in SELinux, I'll prepare patches...

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 23:49             ` Kees Cook
@ 2018-10-01 23:49               ` Kees Cook
  0 siblings, 0 replies; 164+ messages in thread
From: Kees Cook @ 2018-10-01 23:49 UTC (permalink / raw)
  To: John Johansen
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On Mon, Oct 1, 2018 at 4:44 PM, John Johansen
<john.johansen@canonical.com> wrote:
> On 10/01/2018 04:30 PM, Kees Cook wrote:
>> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
>> enabled. Is that okay?
>>
> ugh I would rather get rid of apparmor=0 or to emit a warning with apparmor
> disabled, but if we have to live with it then yes I can live with last
> option wins

Removing it would be much preferred! :)

Assuming Paul is okay with the same results in SELinux, I'll prepare patches...

-Kees

-- 
Kees Cook
Pixel Security

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 23:38           ` Kees Cook
  2018-10-01 23:38             ` Kees Cook
@ 2018-10-01 23:57             ` John Johansen
  2018-10-01 23:57               ` John Johansen
  1 sibling, 1 reply; 164+ messages in thread
From: John Johansen @ 2018-10-01 23:57 UTC (permalink / raw)
  To: Kees Cook
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On 10/01/2018 04:38 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 4:30 PM, Kees Cook <keescook@chromium.org> wrote:
>> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
>> enabled. Is that okay?
> 
> Actually, what the v3 series does right now is leaves AppArmor and
> SELinux alone -- whatever they configured for enable/disable is left
> alone.
> 
> The problem I have is when processing CONFIG_LSM_ENABLE ... what do I
> do with the existing "enable" flag? It's set by both
> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE and apparmor=0/1.
> 
> Right now I can't tell the difference between someone booting with
> apparmor=0 or CONFIG_LSM_ENABLE not including apparmor.
> 
> i.e. how do I mix CONFIG_LSM_ENABLE with apparmor=0/1? (assuming
> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE has been removed)
> 
right, Its a mess and confusing not just us but for the user. I think
it is worth considering removing the apparmor= and apparmor.enabled
options so that we can clean this up.

If we do keep it, there are three options
1. last option wins (above)
2. add more states so we can track the different combination (more
  complex and probably not worth it)
3. we ignore any apparmor=1 (he default state) and only look at
  whether apparmor.enabled has been toggled to 0 during setup. 
  At which point it stays that way.

if we keep it, I think an explicit disable should win, so
option 3, but I can live with 1.

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

* Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable=
  2018-10-01 23:57             ` John Johansen
@ 2018-10-01 23:57               ` John Johansen
  0 siblings, 0 replies; 164+ messages in thread
From: John Johansen @ 2018-10-01 23:57 UTC (permalink / raw)
  To: Kees Cook
  Cc: Paul Moore, James Morris, Casey Schaufler, Tetsuo Handa,
	Stephen Smalley, Schaufler, Casey, LSM, Jonathan Corbet,
	open list:DOCUMENTATION, linux-arch, LKML

On 10/01/2018 04:38 PM, Kees Cook wrote:
> On Mon, Oct 1, 2018 at 4:30 PM, Kees Cook <keescook@chromium.org> wrote:
>> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's
>> enabled. Is that okay?
> 
> Actually, what the v3 series does right now is leaves AppArmor and
> SELinux alone -- whatever they configured for enable/disable is left
> alone.
> 
> The problem I have is when processing CONFIG_LSM_ENABLE ... what do I
> do with the existing "enable" flag? It's set by both
> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE and apparmor=0/1.
> 
> Right now I can't tell the difference between someone booting with
> apparmor=0 or CONFIG_LSM_ENABLE not including apparmor.
> 
> i.e. how do I mix CONFIG_LSM_ENABLE with apparmor=0/1? (assuming
> CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE has been removed)
> 
right, Its a mess and confusing not just us but for the user. I think
it is worth considering removing the apparmor= and apparmor.enabled
options so that we can clean this up.

If we do keep it, there are three options
1. last option wins (above)
2. add more states so we can track the different combination (more
  complex and probably not worth it)
3. we ignore any apparmor=1 (he default state) and only look at
  whether apparmor.enabled has been toggled to 0 during setup. 
  At which point it stays that way.

if we keep it, I think an explicit disable should win, so
option 3, but I can live with 1.

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

end of thread, other threads:[~2018-10-02  6:38 UTC | newest]

Thread overview: 164+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-25  0:18 [PATCH security-next v3 00/29] LSM: Explict LSM ordering Kees Cook
2018-09-25  0:18 ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 01/29] LSM: Correctly announce start of LSM initialization Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 19:53   ` James Morris
2018-10-01 19:53     ` James Morris
2018-10-01 21:05   ` John Johansen
2018-10-01 21:05     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 02/29] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 19:56   ` James Morris
2018-10-01 19:56     ` James Morris
2018-10-01 21:05   ` John Johansen
2018-10-01 21:05     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 03/29] LSM: Rename .security_initcall section to .lsm_info Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 19:57   ` James Morris
2018-10-01 19:57     ` James Morris
2018-10-01 21:06   ` John Johansen
2018-10-01 21:06     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 04/29] LSM: Remove initcall tracing Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-26 16:35   ` Steven Rostedt
2018-09-26 16:35     ` Steven Rostedt
2018-09-26 18:35     ` Kees Cook
2018-09-26 18:35       ` Kees Cook
2018-09-30 23:25       ` Steven Rostedt
2018-09-30 23:25         ` Steven Rostedt
2018-10-01  1:01         ` Kees Cook
2018-10-01  1:01           ` Kees Cook
2018-10-01 21:07   ` John Johansen
2018-10-01 21:07     ` John Johansen
2018-10-01 21:23     ` Steven Rostedt
2018-10-01 21:23       ` Steven Rostedt
2018-10-01 22:38       ` Kees Cook
2018-10-01 22:38         ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 05/29] LSM: Convert from initcall to struct lsm_info Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 19:59   ` James Morris
2018-10-01 19:59     ` James Morris
2018-10-01 21:08   ` John Johansen
2018-10-01 21:08     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 06/29] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:10   ` John Johansen
2018-10-01 21:10     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 07/29] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:12   ` John Johansen
2018-10-01 21:12     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 08/29] LSM: Record LSM name in struct lsm_info Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:13   ` John Johansen
2018-10-01 21:13     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 09/29] LSM: Provide init debugging infrastructure Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:14   ` John Johansen
2018-10-01 21:14     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 10/29] LSM: Don't ignore initialization failures Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:14   ` John Johansen
2018-10-01 21:14     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 11/29] LSM: Introduce LSM_FLAG_LEGACY_MAJOR Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:15   ` John Johansen
2018-10-01 21:15     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 12/29] LSM: Provide separate ordered initialization Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:17   ` John Johansen
2018-10-01 21:17     ` John Johansen
2018-10-01 22:03     ` Kees Cook
2018-10-01 22:03       ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 13/29] LoadPin: Rename "enable" to "enforce" Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:17   ` John Johansen
2018-10-01 21:17     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 14/29] LSM: Plumb visibility into optional "enabled" state Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:18   ` John Johansen
2018-10-01 21:18     ` John Johansen
2018-10-01 21:47   ` James Morris
2018-10-01 21:47     ` James Morris
2018-10-01 21:56     ` Kees Cook
2018-10-01 21:56       ` Kees Cook
2018-10-01 22:20       ` John Johansen
2018-10-01 22:20         ` John Johansen
2018-10-01 22:29         ` Kees Cook
2018-10-01 22:29           ` Kees Cook
2018-10-01 22:53           ` John Johansen
2018-10-01 22:53             ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 15/29] LSM: Lift LSM selection out of individual LSMs Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:18   ` John Johansen
2018-10-01 21:18     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 16/29] LSM: Prepare for arbitrary LSM enabling Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:22   ` John Johansen
2018-10-01 21:22     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 17/29] LSM: Introduce CONFIG_LSM_ENABLE Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:34   ` John Johansen
2018-10-01 21:34     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable= Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:46   ` John Johansen
2018-10-01 21:46     ` John Johansen
2018-10-01 22:27     ` Kees Cook
2018-10-01 22:27       ` Kees Cook
2018-10-01 22:48       ` John Johansen
2018-10-01 22:48         ` John Johansen
2018-10-01 23:30         ` Kees Cook
2018-10-01 23:30           ` Kees Cook
2018-10-01 23:38           ` Kees Cook
2018-10-01 23:38             ` Kees Cook
2018-10-01 23:57             ` John Johansen
2018-10-01 23:57               ` John Johansen
2018-10-01 23:44           ` John Johansen
2018-10-01 23:44             ` John Johansen
2018-10-01 23:49             ` Kees Cook
2018-10-01 23:49               ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 19/29] LSM: Prepare for reorganizing "security=" logic Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-10-01 21:47   ` John Johansen
2018-10-01 21:47     ` John Johansen
2018-09-25  0:18 ` [PATCH security-next v3 20/29] LSM: Refactor "security=" in terms of enable/disable Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 21/29] LSM: Build ordered list of ordered LSMs for init Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 22/29] LSM: Introduce CONFIG_LSM_ORDER Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 23/29] LSM: Introduce "lsm.order=" for boottime ordering Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 24/29] LoadPin: Initialize as ordered LSM Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 25/29] Yama: " Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 26/29] LSM: Introduce enum lsm_order Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 27/29] capability: Initialize as LSM_ORDER_FIRST Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 28/29] LSM: Separate idea of "major" LSM from "exclusive" LSM Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-25  0:18 ` [PATCH security-next v3 29/29] LSM: Add all exclusive LSMs to ordered initialization Kees Cook
2018-09-25  0:18   ` Kees Cook
2018-09-28 15:55 ` [PATCH security-next v3 00/29] LSM: Explict LSM ordering Casey Schaufler
2018-09-28 15:55   ` Casey Schaufler
2018-09-28 20:01   ` Kees Cook
2018-09-28 20:01     ` Kees Cook
2018-09-28 20:25     ` Stephen Smalley
2018-09-28 20:25       ` Stephen Smalley
2018-09-28 20:33       ` Stephen Smalley
2018-09-28 20:33         ` Stephen Smalley
2018-09-28 20:54         ` Kees Cook
2018-09-28 20:54           ` Kees Cook
2018-09-29 10:48     ` Tetsuo Handa
2018-09-29 10:48       ` Tetsuo Handa
2018-09-29 18:18       ` Kees Cook
2018-09-29 18:18         ` Kees Cook
2018-09-30  2:36         ` Tetsuo Handa
2018-09-30  2:36           ` Tetsuo Handa
2018-09-30 16:57           ` Kees Cook
2018-09-30 16:57             ` Kees Cook
2018-09-29 18:19       ` John Johansen
2018-09-29 18:19         ` John Johansen

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