[PATCH security-next v5 00/30] LSM: Explict ordering

[PATCH security-next v5 00/30] LSM: Explict ordering

[Kees Cook]

v5:
- redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
- dropped various Reviewed-bys due to rather large refactoring

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

v3:
- add CONFIG_LSM_ENABLE and refactor resulting logic

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

Overview:

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

Approach:

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

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

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

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

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

With all LSMs being proessed centrally, it was possible to implement a
new boot parameter "lsm=" to provide explicit ordering, which is helpful
for the future "blob sharing" LSMs. Matching this is the new CONFIG_LSM,
which effectively 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 boot param "enabled" to "enforce"
  LSM: Plumb visibility into optional "enabled" state
  LSM: Lift LSM selection out of individual LSMs

Provide centralized LSM ordering infrastructure:
  LSM: Build ordered list of LSMs to initialize
  LSM: Introduce CONFIG_LSM
  LSM: Introduce "lsm=" for boottime LSM selection
  LSM: Tie enabling logic to presence in ordered list

Refactor legacy "security=" handling to map to new infrastructure:
  LSM: Prepare for reorganizing "security=" logic
  LSM: Refactor "security=" in terms of enable/disable

Move major LSMs into ordered initialization:
  LSM: Separate idea of "major" LSM from "exclusive" LSM
  apparmor: Remove SECURITY_APPARMOR_BOOTPARAM_VALUE
  selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUE
  LSM: Add all exclusive LSMs to ordered initialization
  LSM: Split LSM preparation from initialization

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


-Kees

 .../admin-guide/kernel-parameters.txt         |   6 +
 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                     |  36 ++-
 include/linux/module.h                        |   1 -
 security/Kconfig                              |  41 +--
 security/apparmor/Kconfig                     |  16 -
 security/apparmor/lsm.c                       |  17 +-
 security/commoncap.c                          |   9 +-
 security/integrity/iint.c                     |   6 +-
 security/loadpin/Kconfig                      |   4 +-
 security/loadpin/loadpin.c                    |  29 +-
 security/security.c                           | 288 ++++++++++++++----
 security/selinux/Kconfig                      |  15 -
 security/selinux/hooks.c                      |  22 +-
 security/smack/smack_lsm.c                    |   9 +-
 security/tomoyo/tomoyo.c                      |   8 +-
 security/yama/yama_lsm.c                      |   8 +-
 26 files changed, 343 insertions(+), 210 deletions(-)

-- 
2.17.1

[PATCH security-next v5 01/30] LSM: Correctly announce start of LSM initialization

[Kees Cook]

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

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

diff --git a/security/security.c b/security/security.c
index 736e78da1ab9..4cbcf244a965 100644
--- a/security/security.c
+++ b/security/security.c
@@ -72,10 +72,11 @@ int __init security_init(void)
 	int i;
 	struct hlist_head *list = (struct hlist_head *) &security_hook_heads;
 
+	pr_info("Security Framework initializing\n");
+
 	for (i = 0; i < sizeof(security_hook_heads) / sizeof(struct hlist_head);
 	     i++)
 		INIT_HLIST_HEAD(&list[i]);
-	pr_info("Security Framework initialized\n");
 
 	/*
 	 * Load minor LSMs, with the capability module always first.
-- 
2.17.1

[PATCH security-next v5 02/30] vmlinux.lds.h: Avoid copy/paste of security_init section

[Kees Cook]

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

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

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

[PATCH security-next v5 03/30] LSM: Rename .security_initcall section to .lsm_info

[Kees Cook]

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

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

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

[PATCH security-next v5 04/30] LSM: Remove initcall tracing

[Kees Cook]

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

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
---
 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

[PATCH security-next v5 05/30] LSM: Convert from initcall to struct lsm_info

[Kees Cook]

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

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

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

[PATCH security-next v5 06/30] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA

[Kees Cook]

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

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
Reviewed-by: John Johansen <john.johansen@canonical.com>
Reviewed-by: James Morris <james.morris@microsoft.com>
---
 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

[PATCH security-next v5 07/30] LSM: Convert security_initcall() into DEFINE_LSM()

[Kees Cook]

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

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

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

[PATCH security-next v5 08/30] LSM: Record LSM name in struct lsm_info

[Kees Cook]

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

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

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

[PATCH security-next v5 09/30] LSM: Provide init debugging infrastructure

[Kees Cook]

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

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

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

[PATCH security-next v5 10/30] LSM: Don't ignore initialization failures

[Kees Cook]

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

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

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

[PATCH security-next v5 11/30] LSM: Introduce LSM_FLAG_LEGACY_MAJOR

[Kees Cook]

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

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

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

[PATCH security-next v5 12/30] LSM: Provide separate ordered initialization

[Kees Cook]

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

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

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

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

Re: [PATCH security-next v5 12/30] LSM: Provide separate ordered initialization

[Mimi Zohar]

Hi Kees,

On Wed, 2018-10-10 at 17:18 -0700, 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.

I'm so sorry for not reviewing these patches earlier.  Both IMA and
EVM are dependent on "integrity", but "integrity", at least by itself,
should not be considered an LSM.

I don't recall why "integrity" is on the security_initcall, while both
IMA and EVM are on the late_initcall().

Mimi

> 
> Signed-off-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Casey Schaufler <casey@schaufler-ca.com>
> Reviewed-by: John Johansen <john.johansen@canonical.com>
> ---
>  security/security.c | 21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/security/security.c b/security/security.c
> index 2055af907eba..ebbbb672ced5 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -52,12 +52,30 @@ static __initdata bool debug;
>  			pr_info(__VA_ARGS__);			\
>  	} while (0)
> 
> +static void __init ordered_lsm_init(void)
> +{
> +	struct lsm_info *lsm;
> +	int ret;
> +
> +	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
> +		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) != 0)
> +			continue;
> +
> +		init_debug("initializing %s\n", lsm->name);
> +		ret = lsm->init();
> +		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
> +	}
> +}
> +
>  static void __init major_lsm_init(void)
>  {
>  	struct lsm_info *lsm;
>  	int ret;
> 
>  	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
> +		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
> +			continue;
> +
>  		init_debug("initializing %s\n", lsm->name);
>  		ret = lsm->init();
>  		WARN(ret, "%s failed to initialize: %d\n", lsm->name, ret);
> @@ -87,6 +105,9 @@ int __init security_init(void)
>  	yama_add_hooks();
>  	loadpin_add_hooks();
> 
> +	/* Load LSMs in specified order. */
> +	ordered_lsm_init();
> +
>  	/*
>  	 * Load all the remaining security modules.
>  	 */

Re: [PATCH security-next v5 12/30] LSM: Provide separate ordered initialization

[Kees Cook]

On Fri, Nov 2, 2018 at 11:13 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> I don't recall why "integrity" is on the security_initcall, while both
> IMA and EVM are on the late_initcall().

It's because integrity needs to have a VFS buffer allocated extremely
early, so it used the security init to do it. While it's not an LSM,
it does use this part of LSM infrastructure. I didn't see an obvious
alternative at the time, but now that I think about it, maybe just a
simple postcore_initcall() would work?

-Kees

-- 
Kees Cook

Re: [PATCH security-next v5 12/30] LSM: Provide separate ordered initialization

[Mimi Zohar]

On Fri, 2018-11-02 at 13:49 -0700, Kees Cook wrote:
> On Fri, Nov 2, 2018 at 11:13 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > I don't recall why "integrity" is on the security_initcall, while both
> > IMA and EVM are on the late_initcall().
> 
> It's because integrity needs to have a VFS buffer allocated extremely
> early, so it used the security init to do it. While it's not an LSM,
> it does use this part of LSM infrastructure. I didn't see an obvious
> alternative at the time, but now that I think about it, maybe just a
> simple postcore_initcall() would work?

I was questioning why the "security_initcall", which is called after
the late_initcall.  Moving it to the postcore_initcall, before the
late_initcall, sounds right.

Mimi

[PATCH security-next v5 13/30] LoadPin: Rename boot param "enabled" to "enforce"

[Kees Cook]

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

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

diff --git a/security/loadpin/Kconfig b/security/loadpin/Kconfig
index dd01aa91e521..a0d70d82b98e 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_ENFORCE
 	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.enforce=1".
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index 0716af28808a..a2dc146b6364 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 enforce = IS_ENABLED(CONFIG_SECURITY_LOADPIN_ENFORCE);
 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       = "enforce",
+		.data           = &enforce,
 		.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 (!enforce) {
 			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(!enforce)) {
 			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",
+		enforce ? "" : "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(enforce, int, 0);
+MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
-- 
2.17.1

[PATCH security-next v5 14/30] LSM: Plumb visibility into optional "enabled" state

[Kees Cook]

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

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

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

[PATCH security-next v5 15/30] LSM: Lift LSM selection out of individual LSMs

[Kees Cook]

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

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

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 6ec5a0266f21..9ecb623fb39d 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2085,7 +2085,6 @@ static inline void security_delete_hooks(struct security_hook_list *hooks,
 #define __lsm_ro_after_init	__ro_after_init
 #endif /* CONFIG_SECURITY_WRITABLE_HOOKS */
 
-extern int __init security_module_enable(const char *module);
 extern void __init capability_add_hooks(void);
 #ifdef CONFIG_SECURITY_YAMA
 extern void __init yama_add_hooks(void);
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 6ace45704cb6..bc56b058dc75 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1542,12 +1542,6 @@ static int __init apparmor_init(void)
 {
 	int error;
 
-	if (!apparmor_enabled || !security_module_enable("apparmor")) {
-		aa_info_message("AppArmor disabled by boot time parameter");
-		apparmor_enabled = false;
-		return 0;
-	}
-
 	aa_secids_init();
 
 	error = aa_setup_dfa_engine();
diff --git a/security/security.c b/security/security.c
index ebbbb672ced5..8968c98e0a0e 100644
--- a/security/security.c
+++ b/security/security.c
@@ -52,33 +52,96 @@ static __initdata bool debug;
 			pr_info(__VA_ARGS__);			\
 	} while (0)
 
+static bool __init is_enabled(struct lsm_info *lsm)
+{
+	if (!lsm->enabled || *lsm->enabled)
+		return true;
+
+	return false;
+}
+
+/* Mark an LSM's enabled flag. */
+static int lsm_enabled_true __initdata = 1;
+static int lsm_enabled_false __initdata = 0;
+static void __init set_enabled(struct lsm_info *lsm, bool enabled)
+{
+	/*
+	 * When an LSM hasn't configured an enable variable, we can use
+	 * a hard-coded location for storing the default enabled state.
+	 */
+	if (!lsm->enabled) {
+		if (enabled)
+			lsm->enabled = &lsm_enabled_true;
+		else
+			lsm->enabled = &lsm_enabled_false;
+	} else 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? */
+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 initialized. */
+static void __init maybe_initialize_lsm(struct lsm_info *lsm)
+{
+	int enabled = lsm_allowed(lsm);
+
+	/* Record enablement (to handle any following exclusive LSMs). */
+	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 +231,6 @@ static int lsm_append(char *new, char **result)
 	return 0;
 }
 
-/**
- * security_module_enable - Load given security module on boot ?
- * @module: the name of the module
- *
- * Each LSM must pass this method before registering its own operations
- * to avoid security registration races. This method may also be used
- * to check if your LSM is currently loaded during kernel initialization.
- *
- * Returns:
- *
- * true if:
- *
- * - The passed LSM is the one chosen by user at boot time,
- * - or the passed LSM is configured as the default and the user did not
- *   choose an alternate LSM at boot time.
- *
- * Otherwise, return false.
- */
-int __init security_module_enable(const char *module)
-{
-	return !strcmp(module, chosen_lsm);
-}
-
 /**
  * security_add_hooks - Add a modules hooks to the hook lists.
  * @hooks: the hooks to add
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index e8da99550b67..71a10fedecb3 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7133,16 +7133,6 @@ static struct security_hook_list selinux_hooks[] __lsm_ro_after_init = {
 
 static __init int selinux_init(void)
 {
-	if (!security_module_enable("selinux")) {
-		selinux_enabled = 0;
-		return 0;
-	}
-
-	if (!selinux_enabled) {
-		pr_info("SELinux:  Disabled at boot.\n");
-		return 0;
-	}
-
 	pr_info("SELinux:  Initializing.\n");
 
 	memset(&selinux_state, 0, sizeof(selinux_state));
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index db8bc6b6d8b0..f243044d5a55 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4834,9 +4834,6 @@ static __init int smack_init(void)
 	struct cred *cred;
 	struct task_smack *tsp;
 
-	if (!security_module_enable("smack"))
-		return 0;
-
 	smack_inode_cache = KMEM_CACHE(inode_smack, 0);
 	if (!smack_inode_cache)
 		return -ENOMEM;
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 09f7af130d3a..a46f6bc1e97c 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -540,8 +540,6 @@ static int __init tomoyo_init(void)
 {
 	struct cred *cred = (struct cred *) current_cred();
 
-	if (!security_module_enable("tomoyo"))
-		return 0;
 	/* register ourselves with the security framework */
 	security_add_hooks(tomoyo_hooks, ARRAY_SIZE(tomoyo_hooks), "tomoyo");
 	printk(KERN_INFO "TOMOYO Linux initialized\n");
-- 
2.17.1

[PATCH security-next v5 16/30] LSM: Build ordered list of LSMs to initialize

[Kees Cook]

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

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

diff --git a/security/security.c b/security/security.c
index 8968c98e0a0e..9bb15d697287 100644
--- a/security/security.c
+++ b/security/security.c
@@ -37,6 +37,9 @@
 /* Maximum number of letters for an LSM name string */
 #define SECURITY_NAME_MAX	10
 
+/* 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 @@ char *lsm_names;
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
 
+/* Ordered list of LSMs to initialize. */
+static __initdata struct lsm_info **ordered_lsms;
+
 static __initdata bool debug;
 #define init_debug(...)						\
 	do {							\
@@ -85,6 +91,34 @@ 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");
+}
+
 /* Is an LSM allowed to be initialized? */
 static bool __init lsm_allowed(struct lsm_info *lsm)
 {
@@ -121,18 +155,32 @@ static void __init maybe_initialize_lsm(struct lsm_info *lsm)
 	}
 }
 
-static void __init ordered_lsm_init(void)
+/* Populate ordered LSMs list from single LSM name. */
+static void __init ordered_lsm_parse(const char *order, const char *origin)
 {
 	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);
+		if (strcmp(lsm->name, order) == 0)
+			append_ordered_lsm(lsm, origin);
 	}
 }
 
+static void __init ordered_lsm_init(void)
+{
+	struct lsm_info **lsm;
+
+	ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
+				GFP_KERNEL);
+
+	ordered_lsm_parse("integrity", "builtin");
+
+	for (lsm = ordered_lsms; *lsm; lsm++)
+		maybe_initialize_lsm(*lsm);
+
+	kfree(ordered_lsms);
+}
+
 static void __init major_lsm_init(void)
 {
 	struct lsm_info *lsm;
-- 
2.17.1

[PATCH security-next v5 17/30] LSM: Introduce CONFIG_LSM

[Kees Cook]

This provides a way to declare LSM initialization order via the new
CONFIG_LSM. Currently only non-major LSMs are recognized. This will
be expanded in future patches.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 security/Kconfig    |  9 +++++++++
 security/security.c | 27 ++++++++++++++++++++++-----
 2 files changed, 31 insertions(+), 5 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 27d8b2688f75..005634f7c4bb 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -276,5 +276,14 @@ config DEFAULT_SECURITY
 	default "apparmor" if DEFAULT_SECURITY_APPARMOR
 	default "" if DEFAULT_SECURITY_DAC
 
+config LSM
+	string "Ordered list of enabled LSMs"
+	default "integrity"
+	help
+	  A comma-separated list of LSMs, in initialization order.
+	  Any LSMs left off this list will be ignored.
+
+	  If unsure, leave this as the default.
+
 endmenu
 
diff --git a/security/security.c b/security/security.c
index 9bb15d697287..1c4889bce917 100644
--- a/security/security.c
+++ b/security/security.c
@@ -48,6 +48,8 @@ char *lsm_names;
 static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
 	CONFIG_DEFAULT_SECURITY;
 
+static __initconst const char * const builtin_lsm_order = CONFIG_LSM;
+
 /* Ordered list of LSMs to initialize. */
 static __initdata struct lsm_info **ordered_lsms;
 
@@ -155,15 +157,30 @@ static void __init maybe_initialize_lsm(struct lsm_info *lsm)
 	}
 }
 
-/* Populate ordered LSMs list from single LSM name. */
+/* Populate ordered LSMs list from comma-separated LSM name list. */
 static void __init ordered_lsm_parse(const char *order, const char *origin)
 {
 	struct lsm_info *lsm;
+	char *sep, *name, *next;
+
+	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;
+			}
+		}
 
-	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
-		if (strcmp(lsm->name, order) == 0)
-			append_ordered_lsm(lsm, origin);
+		if (!found)
+			init_debug("%s ignored: %s\n", origin, name);
 	}
+	kfree(sep);
 }
 
 static void __init ordered_lsm_init(void)
@@ -173,7 +190,7 @@ static void __init ordered_lsm_init(void)
 	ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
 				GFP_KERNEL);
 
-	ordered_lsm_parse("integrity", "builtin");
+	ordered_lsm_parse(builtin_lsm_order, "builtin");
 
 	for (lsm = ordered_lsms; *lsm; lsm++)
 		maybe_initialize_lsm(*lsm);
-- 
2.17.1

[PATCH security-next v5 18/30] LSM: Introduce "lsm=" for boottime LSM selection

[Kees Cook]

Provide a way to explicitly choose LSM initialization order via the new
"lsm=" comma-separated list of LSMs.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  4 ++++
 security/Kconfig                                |  3 ++-
 security/security.c                             | 14 +++++++++++++-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 32d323ee9218..d6389ab66f49 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2276,6 +2276,10 @@
 
 	lsm.debug	[SECURITY] Enable LSM initialization debugging output.
 
+	lsm=lsm1,...,lsmN
+			[SECURITY] Choose order of LSM initialization. This
+			overrides CONFIG_LSM.
+
 	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 005634f7c4bb..0aa82c1c928e 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -281,7 +281,8 @@ config LSM
 	default "integrity"
 	help
 	  A comma-separated list of LSMs, in initialization order.
-	  Any LSMs left off this list will be ignored.
+	  Any LSMs left off this list will be ignored. This can be
+	  controlled at boot with the "lsm=" parameter.
 
 	  If unsure, leave this as the default.
 
diff --git a/security/security.c b/security/security.c
index 1c4889bce917..70cb2d0004e9 100644
--- a/security/security.c
+++ b/security/security.c
@@ -47,6 +47,7 @@ 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_order;
 
 static __initconst const char * const builtin_lsm_order = CONFIG_LSM;
 
@@ -190,7 +191,10 @@ static void __init ordered_lsm_init(void)
 	ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
 				GFP_KERNEL);
 
-	ordered_lsm_parse(builtin_lsm_order, "builtin");
+	if (chosen_lsm_order)
+		ordered_lsm_parse(chosen_lsm_order, "cmdline");
+	else
+		ordered_lsm_parse(builtin_lsm_order, "builtin");
 
 	for (lsm = ordered_lsms; *lsm; lsm++)
 		maybe_initialize_lsm(*lsm);
@@ -252,6 +256,14 @@ static int __init choose_lsm(char *str)
 }
 __setup("security=", choose_lsm);
 
+/* Explicitly choose LSM initialization order. */
+static int __init choose_lsm_order(char *str)
+{
+	chosen_lsm_order = str;
+	return 1;
+}
+__setup("lsm=", choose_lsm_order);
+
 /* Enable LSM order debugging. */
 static int __init enable_debug(char *str)
 {
-- 
2.17.1

[PATCH security-next v5 19/30] LSM: Tie enabling logic to presence in ordered list

[Kees Cook]

Until now, any LSM without an enable storage variable was considered
enabled. This inverts the logic and sets defaults to true only if the
LSM gets added to the ordered initialization list. (And an exception
continues for the major LSMs until they are integrated into the ordered
initialization in a later patch.)

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/lsm_hooks.h |  2 +-
 security/security.c       | 14 +++++++++++---
 2 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 9ecb623fb39d..b6b05d351eb4 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2044,7 +2044,7 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 struct lsm_info {
 	const char *name;	/* Required. */
 	unsigned long flags;	/* Optional: flags describing LSM */
-	int *enabled;		/* Optional: NULL means enabled. */
+	int *enabled;		/* Optional: controlled by CONFIG_LSM */
 	int (*init)(void);	/* Required. */
 };
 
diff --git a/security/security.c b/security/security.c
index 70cb2d0004e9..f3777ed4ca80 100644
--- a/security/security.c
+++ b/security/security.c
@@ -63,10 +63,10 @@ static __initdata bool debug;
 
 static bool __init is_enabled(struct lsm_info *lsm)
 {
-	if (!lsm->enabled || *lsm->enabled)
-		return true;
+	if (!lsm->enabled)
+		return false;
 
-	return false;
+	return *lsm->enabled;
 }
 
 /* Mark an LSM's enabled flag. */
@@ -117,7 +117,11 @@ static void __init append_ordered_lsm(struct lsm_info *lsm, const char *from)
 	if (WARN(last_lsm == LSM_COUNT, "%s: out of LSM slots!?\n", from))
 		return;
 
+	/* Enable this LSM, if it is not already set. */
+	if (!lsm->enabled)
+		lsm->enabled = &lsm_enabled_true;
 	ordered_lsms[last_lsm++] = lsm;
+
 	init_debug("%s ordering: %s (%sabled)\n", from, lsm->name,
 		   is_enabled(lsm) ? "en" : "dis");
 }
@@ -210,6 +214,10 @@ static void __init major_lsm_init(void)
 		if ((lsm->flags & LSM_FLAG_LEGACY_MAJOR) == 0)
 			continue;
 
+		/* Enable this LSM, if it is not already set. */
+		if (!lsm->enabled)
+			lsm->enabled = &lsm_enabled_true;
+
 		maybe_initialize_lsm(lsm);
 	}
 }
-- 
2.17.1

[PATCH security-next v5 20/30] LSM: Prepare for reorganizing "security=" logic

[Kees Cook]

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

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

diff --git a/security/security.c b/security/security.c
index f3777ed4ca80..1b1ee823457c 100644
--- a/security/security.c
+++ b/security/security.c
@@ -34,9 +34,6 @@
 
 #define MAX_LSM_EVM_XATTR	2
 
-/* Maximum number of letters for an LSM name string */
-#define SECURITY_NAME_MAX	10
-
 /* How many LSMs were built into the kernel? */
 #define LSM_COUNT (__end_lsm_info - __start_lsm_info)
 
@@ -45,9 +42,8 @@ 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_order;
+static __initdata const char *chosen_major_lsm;
 
 static __initconst const char * const builtin_lsm_order = CONFIG_LSM;
 
@@ -138,7 +134,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;
@@ -195,6 +191,9 @@ static void __init ordered_lsm_init(void)
 	ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
 				GFP_KERNEL);
 
+	if (!chosen_major_lsm)
+		chosen_major_lsm = CONFIG_DEFAULT_SECURITY;
+
 	if (chosen_lsm_order)
 		ordered_lsm_parse(chosen_lsm_order, "cmdline");
 	else
@@ -257,12 +256,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);
 
 /* Explicitly choose LSM initialization order. */
 static int __init choose_lsm_order(char *str)
-- 
2.17.1

[PATCH security-next v5 21/30] LSM: Refactor "security=" in terms of enable/disable

[Kees Cook]

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

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

diff --git a/security/security.c b/security/security.c
index 1b1ee823457c..2c754968f98b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -129,14 +129,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;
 }
 
@@ -191,8 +183,28 @@ static void __init ordered_lsm_init(void)
 	ordered_lsms = kcalloc(LSM_COUNT + 1, sizeof(*ordered_lsms),
 				GFP_KERNEL);
 
+	/* Process "security=", if given. */
 	if (!chosen_major_lsm)
 		chosen_major_lsm = CONFIG_DEFAULT_SECURITY;
+	if (chosen_major_lsm) {
+		struct lsm_info *major;
+
+		/*
+		 * 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 (major = __start_lsm_info; major < __end_lsm_info;
+		     major++) {
+			if ((major->flags & LSM_FLAG_LEGACY_MAJOR) &&
+			    strcmp(major->name, chosen_major_lsm) != 0) {
+				set_enabled(major, false);
+				init_debug("security=%s disabled: %s\n",
+					   chosen_major_lsm, major->name);
+			}
+		}
+	}
 
 	if (chosen_lsm_order)
 		ordered_lsm_parse(chosen_lsm_order, "cmdline");
-- 
2.17.1

[PATCH security-next v5 22/30] LSM: Separate idea of "major" LSM from "exclusive" LSM

[Kees Cook]

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

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

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index b6b05d351eb4..e88c725a43b8 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)
 
 struct lsm_info {
 	const char *name;	/* Required. */
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index bc56b058dc75..ebf63461a79c 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -1602,7 +1602,7 @@ static int __init apparmor_init(void)
 
 DEFINE_LSM(apparmor) = {
 	.name = "apparmor",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &apparmor_enabled,
 	.init = apparmor_init,
 };
diff --git a/security/security.c b/security/security.c
index 2c754968f98b..65f1fa733e4b 100644
--- a/security/security.c
+++ b/security/security.c
@@ -49,6 +49,7 @@ static __initconst const char * const builtin_lsm_order = CONFIG_LSM;
 
 /* Ordered list of LSMs to initialize. */
 static __initdata struct lsm_info **ordered_lsms;
+static __initdata struct lsm_info *exclusive;
 
 static __initdata bool debug;
 #define init_debug(...)						\
@@ -129,6 +130,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;
 }
 
@@ -144,6 +151,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 chosen: %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 71a10fedecb3..0f8d7bb88197 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -7194,7 +7194,7 @@ void selinux_complete_init(void)
    all processes and objects when they are created. */
 DEFINE_LSM(selinux) = {
 	.name = "selinux",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.enabled = &selinux_enabled,
 	.init = selinux_init,
 };
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index f243044d5a55..92e4baa342f8 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -4881,6 +4881,6 @@ static __init int smack_init(void)
  */
 DEFINE_LSM(smack) = {
 	.name = "smack",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = smack_init,
 };
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index a46f6bc1e97c..daff7d7897ad 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -550,6 +550,6 @@ static int __init tomoyo_init(void)
 
 DEFINE_LSM(tomoyo) = {
 	.name = "tomoyo",
-	.flags = LSM_FLAG_LEGACY_MAJOR,
+	.flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE,
 	.init = tomoyo_init,
 };
-- 
2.17.1

[PATCH security-next v5 23/30] apparmor: Remove SECURITY_APPARMOR_BOOTPARAM_VALUE

[Kees Cook]

In preparation for removing CONFIG_DEFAULT_SECURITY, this removes the
soon-to-be redundant SECURITY_APPARMOR_BOOTPARAM_VALUE. Since explicit
ordering via CONFIG_LSM or "lsm=" will define whether an LSM is enabled or
not, this CONFIG will become effectively ignored, so remove it. However,
in order to stay backward-compatible with "security=apparmor", the enable
variable defaults to true.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 security/apparmor/Kconfig | 16 ----------------
 security/apparmor/lsm.c   |  2 +-
 2 files changed, 1 insertion(+), 17 deletions(-)

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 ebf63461a79c..9eaf1dec2e61 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 int apparmor_enabled = CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE;
+static int apparmor_enabled __lsm_ro_after_init = 1;
 module_param_named(enabled, apparmor_enabled, int, 0444);
 
 static int __init apparmor_enabled_setup(char *str)
-- 
2.17.1

[PATCH security-next v5 24/30] selinux: Remove SECURITY_SELINUX_BOOTPARAM_VALUE

[Kees Cook]

In preparation for removing CONFIG_DEFAULT_SECURITY, this removes the
soon-to-be redundant SECURITY_SELINUX_BOOTPARAM_VALUE. Since explicit
ordering via CONFIG_LSM or "lsm=" will define whether an LSM is enabled or
not, this CONFIG will become effectively ignored, so remove it. However,
in order to stay backward-compatible with "security=selinux", the enable
variable defaults to true.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 security/selinux/Kconfig | 15 ---------------
 security/selinux/hooks.c |  5 +----
 2 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
index 8af7a690eb40..55f032f1fc2d 100644
--- a/security/selinux/Kconfig
+++ b/security/selinux/Kconfig
@@ -22,21 +22,6 @@ config SECURITY_SELINUX_BOOTPARAM
 
 	  If you are unsure how to answer this question, answer N.
 
-config SECURITY_SELINUX_BOOTPARAM_VALUE
-	int "NSA SELinux boot parameter default value"
-	depends on SECURITY_SELINUX_BOOTPARAM
-	range 0 1
-	default 1
-	help
-	  This option sets the default value for the kernel parameter
-	  'selinux', which allows SELinux to be disabled at boot.  If this
-	  option is set to 0 (zero), the SELinux kernel parameter will
-	  default to 0, disabling SELinux at bootup.  If this option is
-	  set to 1 (one), the SELinux kernel parameter will default to 1,
-	  enabling SELinux at bootup.
-
-	  If you are unsure how to answer this question, answer 1.
-
 config SECURITY_SELINUX_DISABLE
 	bool "NSA SELinux runtime disable"
 	depends on SECURITY_SELINUX
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 0f8d7bb88197..14c120842ab4 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -120,9 +120,8 @@ __setup("enforcing=", enforcing_setup);
 #define selinux_enforcing_boot 1
 #endif
 
+int selinux_enabled __lsm_ro_after_init = 1;
 #ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
-int selinux_enabled = CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE;
-
 static int __init selinux_enabled_setup(char *str)
 {
 	unsigned long enabled;
@@ -131,8 +130,6 @@ static int __init selinux_enabled_setup(char *str)
 	return 1;
 }
 __setup("selinux=", selinux_enabled_setup);
-#else
-int selinux_enabled = 1;
 #endif
 
 static unsigned int selinux_checkreqprot_boot =
-- 
2.17.1

[PATCH security-next v5 25/30] LSM: Add all exclusive LSMs to ordered initialization

[Kees Cook]

This removes CONFIG_DEFAULT_SECURITY in favor of the explicit ordering
offered by CONFIG_LSM 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. All
LSMs not added to the ordered list are explicitly disabled.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 security/Kconfig    | 39 +--------------------------------------
 security/security.c | 35 ++++++++++-------------------------
 2 files changed, 11 insertions(+), 63 deletions(-)

diff --git a/security/Kconfig b/security/Kconfig
index 0aa82c1c928e..2f8dc1f59cae 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -239,46 +239,9 @@ source security/yama/Kconfig
 
 source security/integrity/Kconfig
 
-choice
-	prompt "Default security module"
-	default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX
-	default DEFAULT_SECURITY_SMACK if SECURITY_SMACK
-	default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO
-	default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR
-	default DEFAULT_SECURITY_DAC
-
-	help
-	  Select the security module that will be used by default if the
-	  kernel parameter security= is not specified.
-
-	config DEFAULT_SECURITY_SELINUX
-		bool "SELinux" if SECURITY_SELINUX=y
-
-	config DEFAULT_SECURITY_SMACK
-		bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y
-
-	config DEFAULT_SECURITY_TOMOYO
-		bool "TOMOYO" if SECURITY_TOMOYO=y
-
-	config DEFAULT_SECURITY_APPARMOR
-		bool "AppArmor" if SECURITY_APPARMOR=y
-
-	config DEFAULT_SECURITY_DAC
-		bool "Unix Discretionary Access Controls"
-
-endchoice
-
-config DEFAULT_SECURITY
-	string
-	default "selinux" if DEFAULT_SECURITY_SELINUX
-	default "smack" if DEFAULT_SECURITY_SMACK
-	default "tomoyo" if DEFAULT_SECURITY_TOMOYO
-	default "apparmor" if DEFAULT_SECURITY_APPARMOR
-	default "" if DEFAULT_SECURITY_DAC
-
 config LSM
 	string "Ordered list of enabled LSMs"
-	default "integrity"
+	default "integrity,selinux,smack,tomoyo,apparmor"
 	help
 	  A comma-separated list of LSMs, in initialization order.
 	  Any LSMs left off this list will be ignored. This can be
diff --git a/security/security.c b/security/security.c
index 65f1fa733e4b..4f52bd06705f 100644
--- a/security/security.c
+++ b/security/security.c
@@ -175,8 +175,7 @@ static void __init ordered_lsm_parse(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 &&
-			    strcmp(lsm->name, name) == 0) {
+			if (strcmp(lsm->name, name) == 0) {
 				append_ordered_lsm(lsm, origin);
 				found = true;
 			}
@@ -185,6 +184,15 @@ static void __init ordered_lsm_parse(const char *order, const char *origin)
 		if (!found)
 			init_debug("%s ignored: %s\n", origin, name);
 	}
+
+	/* Disable all LSMs not in the ordered list. */
+	for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
+		if (exists_ordered_lsm(lsm))
+			continue;
+		set_enabled(lsm, false);
+		init_debug("%s disabled: %s\n", origin, lsm->name);
+	}
+
 	kfree(sep);
 }
 
@@ -196,8 +204,6 @@ static void __init ordered_lsm_init(void)
 				GFP_KERNEL);
 
 	/* Process "security=", if given. */
-	if (!chosen_major_lsm)
-		chosen_major_lsm = CONFIG_DEFAULT_SECURITY;
 	if (chosen_major_lsm) {
 		struct lsm_info *major;
 
@@ -229,22 +235,6 @@ static void __init ordered_lsm_init(void)
 	kfree(ordered_lsms);
 }
 
-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;
-
-		/* Enable this LSM, if it is not already set. */
-		if (!lsm->enabled)
-			lsm->enabled = &lsm_enabled_true;
-
-		maybe_initialize_lsm(lsm);
-	}
-}
-
 /**
  * security_init - initializes the security framework
  *
@@ -271,11 +261,6 @@ int __init security_init(void)
 	/* Load LSMs in specified order. */
 	ordered_lsm_init();
 
-	/*
-	 * Load all the remaining security modules.
-	 */
-	major_lsm_init();
-
 	return 0;
 }
 
-- 
2.17.1

[PATCH security-next v5 26/30] LSM: Split LSM preparation from initialization

[Kees Cook]

Since we already have to do a pass through the LSMs to figure out if
exclusive LSMs should be disabled after the first one is seen as enabled,
this splits the logic up a bit more cleanly. Now we do a full "prepare"
pass through the LSMs (which also allows for later use by the blob-sharing
code), before starting the LSM initialization pass.

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 security/security.c | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/security/security.c b/security/security.c
index 4f52bd06705f..b40c4c212892 100644
--- a/security/security.c
+++ b/security/security.c
@@ -139,22 +139,28 @@ static bool __init lsm_allowed(struct lsm_info *lsm)
 	return true;
 }
 
-/* Check if LSM should be initialized. */
-static void __init maybe_initialize_lsm(struct lsm_info *lsm)
+/* Prepare LSM for initialization. */
+static void __init prepare_lsm(struct lsm_info *lsm)
 {
 	int enabled = lsm_allowed(lsm);
 
 	/* Record enablement (to handle any following exclusive LSMs). */
 	set_enabled(lsm, enabled);
 
-	/* If selected, initialize the LSM. */
+	/* If enabled, do pre-initialization work. */
 	if (enabled) {
-		int ret;
-
 		if ((lsm->flags & LSM_FLAG_EXCLUSIVE) && !exclusive) {
 			exclusive = lsm;
 			init_debug("exclusive chosen: %s\n", lsm->name);
 		}
+	}
+}
+
+/* Initialize a given LSM, if it is enabled. */
+static void __init initialize_lsm(struct lsm_info *lsm)
+{
+	if (is_enabled(lsm)) {
+		int ret;
 
 		init_debug("initializing %s\n", lsm->name);
 		ret = lsm->init();
@@ -230,7 +236,10 @@ static void __init ordered_lsm_init(void)
 		ordered_lsm_parse(builtin_lsm_order, "builtin");
 
 	for (lsm = ordered_lsms; *lsm; lsm++)
-		maybe_initialize_lsm(*lsm);
+		prepare_lsm(*lsm);
+
+	for (lsm = ordered_lsms; *lsm; lsm++)
+		initialize_lsm(*lsm);
 
 	kfree(ordered_lsms);
 }
-- 
2.17.1

[PATCH security-next v5 27/30] LoadPin: Initialize as ordered LSM

[Kees Cook]

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

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

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index e88c725a43b8..e6893ff9ca2b 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2092,10 +2092,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 2f8dc1f59cae..550bd7032ab2 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -241,7 +241,7 @@ source security/integrity/Kconfig
 
 config LSM
 	string "Ordered list of enabled LSMs"
-	default "integrity,selinux,smack,tomoyo,apparmor"
+	default "loadpin,integrity,selinux,smack,tomoyo,apparmor"
 	help
 	  A comma-separated list of LSMs, in initialization order.
 	  Any LSMs left off this list will be ignored. This can be
diff --git a/security/loadpin/loadpin.c b/security/loadpin/loadpin.c
index a2dc146b6364..640d9c69cf2e 100644
--- a/security/loadpin/loadpin.c
+++ b/security/loadpin/loadpin.c
@@ -184,13 +184,19 @@ static struct security_hook_list loadpin_hooks[] __lsm_ro_after_init = {
 	LSM_HOOK_INIT(kernel_load_data, loadpin_load_data),
 };
 
-void __init loadpin_add_hooks(void)
+static int __init loadpin_init(void)
 {
 	pr_info("ready to pin (currently %senforcing)\n",
 		enforce ? "" : "not ");
 	security_add_hooks(loadpin_hooks, ARRAY_SIZE(loadpin_hooks), "loadpin");
+	return 0;
 }
 
+DEFINE_LSM(loadpin) = {
+	.name = "loadpin",
+	.init = loadpin_init,
+};
+
 /* Should not be mutable after boot, so not listed in sysfs (perm == 0). */
 module_param(enforce, int, 0);
 MODULE_PARM_DESC(enforce, "Enforce module/firmware pinning");
diff --git a/security/security.c b/security/security.c
index b40c4c212892..6ad1262aa6ab 100644
--- a/security/security.c
+++ b/security/security.c
@@ -265,7 +265,6 @@ int __init security_init(void)
 	 */
 	capability_add_hooks();
 	yama_add_hooks();
-	loadpin_add_hooks();
 
 	/* Load LSMs in specified order. */
 	ordered_lsm_init();
-- 
2.17.1

[PATCH security-next v5 28/30] Yama: Initialize as ordered LSM

[Kees Cook]

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

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

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index e6893ff9ca2b..833ec0f03795 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2087,10 +2087,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 550bd7032ab2..f2a04f922ede 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -241,7 +241,7 @@ source security/integrity/Kconfig
 
 config LSM
 	string "Ordered list of enabled LSMs"
-	default "loadpin,integrity,selinux,smack,tomoyo,apparmor"
+	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 ignored. This can be
diff --git a/security/security.c b/security/security.c
index 6ad1262aa6ab..2eb8afdd945d 100644
--- a/security/security.c
+++ b/security/security.c
@@ -264,7 +264,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. */
 	ordered_lsm_init();
diff --git a/security/yama/yama_lsm.c b/security/yama/yama_lsm.c
index ffda91a4a1aa..eb1da1303d2e 100644
--- a/security/yama/yama_lsm.c
+++ b/security/yama/yama_lsm.c
@@ -477,9 +477,15 @@ static void __init yama_init_sysctl(void)
 static inline void yama_init_sysctl(void) { }
 #endif /* CONFIG_SYSCTL */
 
-void __init yama_add_hooks(void)
+static int __init yama_init(void)
 {
 	pr_info("Yama: becoming mindful.\n");
 	security_add_hooks(yama_hooks, ARRAY_SIZE(yama_hooks), "yama");
 	yama_init_sysctl();
+	return 0;
 }
+
+DEFINE_LSM(yama) = {
+	.name = "yama",
+	.init = yama_init,
+};
-- 
2.17.1

[PATCH security-next v5 29/30] LSM: Introduce enum lsm_order

[Kees Cook]

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

Signed-off-by: Kees Cook <keescook@chromium.org>
---
 include/linux/lsm_hooks.h | 6 ++++++
 security/security.c       | 9 ++++++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 833ec0f03795..97898679a505 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2042,8 +2042,14 @@ extern void security_add_hooks(struct security_hook_list *hooks, int count,
 #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. */
+	LSM_ORDER_MUTABLE = 0,
+};
+
 struct lsm_info {
 	const char *name;	/* Required. */
+	enum lsm_order order;	/* Optional: default is LSM_ORDER_MUTABLE */
 	unsigned long flags;	/* Optional: flags describing LSM */
 	int *enabled;		/* Optional: controlled by CONFIG_LSM */
 	int (*init)(void);	/* Required. */
diff --git a/security/security.c b/security/security.c
index 2eb8afdd945d..004938eb8e70 100644
--- a/security/security.c
+++ b/security/security.c
@@ -174,6 +174,12 @@ static void __init ordered_lsm_parse(const char *order, const char *origin)
 	struct lsm_info *lsm;
 	char *sep, *name, *next;
 
+	/* 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");
+	}
+
 	sep = kstrdup(order, GFP_KERNEL);
 	next = sep;
 	/* Walk the list, looking for matching LSMs. */
@@ -181,7 +187,8 @@ static void __init ordered_lsm_parse(const char *order, const char *origin)
 		bool found = false;
 
 		for (lsm = __start_lsm_info; lsm < __end_lsm_info; lsm++) {
-			if (strcmp(lsm->name, name) == 0) {
+			if (lsm->order == LSM_ORDER_MUTABLE &&
+			    strcmp(lsm->name, name) == 0) {
 				append_ordered_lsm(lsm, origin);
 				found = true;
 			}
-- 
2.17.1

[PATCH security-next v5 30/30] capability: Initialize as LSM_ORDER_FIRST

[Kees Cook]

This converts capabilities to use the new LSM_ORDER_FIRST position.

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

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 97898679a505..b728cb448957 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -2092,6 +2092,4 @@ static inline void security_delete_hooks(struct security_hook_list *hooks,
 #define __lsm_ro_after_init	__ro_after_init
 #endif /* CONFIG_SECURITY_WRITABLE_HOOKS */
 
-extern void __init capability_add_hooks(void);
-
 #endif /* ! __LINUX_LSM_HOOKS_H */
diff --git a/security/commoncap.c b/security/commoncap.c
index 2e489d6a3ac8..c928eb3fe784 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1366,10 +1366,17 @@ struct security_hook_list capability_hooks[] __lsm_ro_after_init = {
 	LSM_HOOK_INIT(vm_enough_memory, cap_vm_enough_memory),
 };
 
-void __init capability_add_hooks(void)
+static int __init capability_init(void)
 {
 	security_add_hooks(capability_hooks, ARRAY_SIZE(capability_hooks),
 				"capability");
+	return 0;
 }
 
+DEFINE_LSM(capability) = {
+	.name = "capability",
+	.order = LSM_ORDER_FIRST,
+	.init = capability_init,
+};
+
 #endif /* CONFIG_SECURITY */
diff --git a/security/security.c b/security/security.c
index 004938eb8e70..aa91181133c1 100644
--- a/security/security.c
+++ b/security/security.c
@@ -267,11 +267,6 @@ int __init security_init(void)
 	     i++)
 		INIT_HLIST_HEAD(&list[i]);
 
-	/*
-	 * Load minor LSMs, with the capability module always first.
-	 */
-	capability_add_hooks();
-
 	/* Load LSMs in specified order. */
 	ordered_lsm_init();
 
-- 
2.17.1

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[James Morris]

On Wed, 10 Oct 2018, Kees Cook wrote:

> v5:
> - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
> - dropped various Reviewed-bys due to rather large refactoring

Patches 1-10 applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general
and next-testing.


-- 
James Morris
<jmorris@namei.org>

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Kees Cook]

On Wed, Oct 10, 2018 at 8:45 PM, James Morris <jmorris@namei.org> wrote:
> On Wed, 10 Oct 2018, Kees Cook wrote:
>
>> v5:
>> - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
>> - dropped various Reviewed-bys due to rather large refactoring
>
> Patches 1-10 applied to
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general
> and next-testing.

Very cool; thanks!

As for the rest, I could post some examples of how the new CONFIG_LSM
and "lsm=..." work (and how they mix with the "legacy" options). Would
that be helpful?

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[James Morris]

On Thu, 11 Oct 2018, Kees Cook wrote:

> On Wed, Oct 10, 2018 at 8:45 PM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 10 Oct 2018, Kees Cook wrote:
> >
> >> v5:
> >> - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
> >> - dropped various Reviewed-bys due to rather large refactoring
> >
> > Patches 1-10 applied to
> > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general
> > and next-testing.
> 
> Very cool; thanks!
> 
> As for the rest, I could post some examples of how the new CONFIG_LSM
> and "lsm=..." work (and how they mix with the "legacy" options). Would
> that be helpful?

Yes, thanks.

-- 
James Morris
<jmorris@namei.org>

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Kees Cook]

On Wed, Oct 10, 2018 at 5:18 PM, Kees Cook <keescook@chromium.org> wrote:
> v5:
> - redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
> - dropped various Reviewed-bys due to rather large refactoring

Here's a tl;dr of the behavioral changes...

Right now, we have:

- hard-coded special LSM: capability which cannot be disabled.
- hard-coded "minor" LSMs: they are enabled in a static order based on
whether they are built into the kernel or not: yama, loadpin.
- a single LSM without a specified order because it only uses the
early-init position: integrity.
- "major" LSMs that are selected via CONFIG_DEFAULT_SECURITY= or
"security=" boot param.
- SELinux and AppArmor each can enable/disable themselves via
CONFIG_..._BOOTPARAM_VALUE= and selinux=/apparmor=.

So, right now, systems will have all the minor LSMs and integrity
initialized if they are built into the kernel without any way to
control their order or disable them at boot time. To select a major
LSM, the pattern is:

selinux=1 security=selinux

Note that both are used here because if you built with
CONFIG_SELINUX_BOOTPARAM_VALUE=0 and CONFIG_DEFAULT_SECURITY=apparmor,
just booting with "security=selinux" just disables AppArmor but
SELinux stays disabled. So the documented way to switch majors is with
"selinux=1 security=selinux". *However* Tomoyo and Smack do not have
separate enable/disable logic. They will work fine with just
"security=smack".

Now, in order to gain arbitrary LSM ordering, this series introduces
CONFIG_LSM= (to replace CONFIG_DEFAULT_SECURITY=) and "lsm=" (to
replace "security="). Note that "security=" has not been removed -- it
will still work. Mixing it with "lsm=" can lead to situations where
"security=" becomes effectively ignored, though.

In the rest of this I'm going to ignore capability: it will always be
first and it will always be enabled.

Assuming that all LSMs are built in (e.g. yama, loadpin, selinux,
smack, tomoyo, apparmor, integrity), here are the changes:

To choose the "default major LSM" of AppArmor before:
CONFIG_DEFAULT_SECURITY=apparmor

To choose the "default major LSM" of AppArmor _without_ extreme stacking now:
CONFIG_LSM=yama,loadpin,integrity,apparmor

To choose the "default major LSM" of AppArmor with future extreme stacking now:
CONFIG_LSM=yama,loadpin,integrity,apparmor,tomoyo,selinux,smack

Whichever exclusive LSM is listed _first_ will be the first to attempt
initialization. Any non-conflicting LSMs following it will initialize
too.

This means a distro can disable the "blob-sharing" behavior by just
providing a CONFIG_LSM= that includes a single major LSM.

To switch to SELinux at boot time with
"CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
work:

selinux=1 security=selinux

This will work still, since it will enable selinux (selinux=1) and
disable all other major LSMs (security=selinux).

The new way to enable selinux would be using
"lsm=yama,loadpin,integrity,selinux".

To see the behaviors, you can boot with "lsm.debug". (Note that
CONFIG_LSM= and "lsm=" are handled exactly the same, so a boot with
"lsm=" would see the same results as a boot without "lsm=", but with
CONFIG_LSM= set to that string.) An example:

lsm.debug lsm=integrity,cows,loadpin,capability,apparmor,tomoyo
selinux=1 security=selinux

produces:

[    0.292502] LSM: Security Framework initializing
[    0.293109] LSM: security=selinux disabled: smack
[    0.293464] LSM: security=selinux disabled: tomoyo
[    0.294464] LSM: security=selinux disabled: apparmor
[    0.295109] LSM: first ordering: capability (enabled)
[    0.295464] LSM: cmdline ordering: integrity (enabled)
[    0.296464] LSM: cmdline ignored: cows
[    0.296953] LSM: cmdline ordering: loadpin (enabled)
[    0.297464] LSM: cmdline ignored: capability
[    0.298464] LSM: cmdline ordering: apparmor (disabled)
[    0.299136] LSM: cmdline ordering: tomoyo (disabled)
[    0.299464] LSM: security= ordering: selinux (enabled)
[    0.300464] LSM: cmdline disabled: smack
[    0.300979] LSM: cmdline disabled: yama
[    0.301464] LSM: exclusive chosen: selinux
[    0.302008] LSM: initializing capability
[    0.302464] LSM: initializing integrity
[    0.302968] LSM: initializing loadpin
[    0.303464] LoadPin: ready to pin (currently not enforcing)
[    0.304464] LSM: initializing selinux
[    0.304946] SELinux:  Initializing.

With yama left out of lsm=, it is disabled. Invalid,
non-mutable-order, or unbuilt LSMs are ignored (i.e. "cows" and
"capability" above). "security=selinux" disables all the other majors
(their ordering is left alone) and things not mentioned in lsm= and[1]
security= are explicitly disabled (and left out of the ordering).

Another example, without "security="...

lsm.debug lsm=integrity,yama,cows,loadpin,capability,apparmor,tomoyo,selinux,smack

[    0.291697] LSM: Security Framework initializing
[    0.292660] LSM: first ordering: capability (enabled)
[    0.293337] LSM: cmdline ordering: integrity (enabled)
[    0.293659] LSM: cmdline ordering: yama (enabled)
[    0.294659] LSM: cmdline ignored: cows
[    0.295169] LSM: cmdline ordering: loadpin (enabled)
[    0.295659] LSM: cmdline ignored: capability
[    0.296231] LSM: cmdline ordering: apparmor (enabled)
[    0.296659] LSM: cmdline ordering: tomoyo (enabled)
[    0.297659] LSM: cmdline ordering: selinux (enabled)
[    0.298659] LSM: cmdline ordering: smack (enabled)
[    0.299309] LSM: exclusive chosen: apparmor
[    0.299659] LSM: exclusive disabled: tomoyo
[    0.300216] LSM: exclusive disabled: selinux
[    0.300659] LSM: exclusive disabled: smack
[    0.301208] LSM: initializing capability
[    0.301659] LSM: initializing integrity
[    0.302662] LSM: initializing yama
[    0.303124] Yama: becoming mindful.
[    0.303666] LSM: initializing loadpin
[    0.304164] LoadPin: ready to pin (currently not enforcing)
[    0.304660] LSM: initializing apparmor
[    0.305179] AppArmor: AppArmor initialized

Given that apparmor is listed first, its exclusivity disables the
other exclusive LSMs, and initialization proceeds.

So, this should work for all the cases we've got coming, as far as I can see! :)

-Kees

[1] In testing v5, I did discover one glitch in my "security="
handling, which I've fixed locally now for v6.

-- 
Kees Cook
Pixel Security

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Jordan Glover]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, October 11, 2018 7:57 PM, Kees Cook <keescook@chromium.org> wrote:

> On Wed, Oct 10, 2018 at 5:18 PM, Kees Cook keescook@chromium.org wrote:
>
> > v5:
> >
> > -   redesigned to use CONFIG_LSM= and lsm= for both ordering and enabling
> > -   dropped various Reviewed-bys due to rather large refactoring
>
> Here's a tl;dr of the behavioral changes...
>
> Right now, we have:
>
> -   hard-coded special LSM: capability which cannot be disabled.
> -   hard-coded "minor" LSMs: they are enabled in a static order based on
>     whether they are built into the kernel or not: yama, loadpin.
>
> -   a single LSM without a specified order because it only uses the
>     early-init position: integrity.
>
> -   "major" LSMs that are selected via CONFIG_DEFAULT_SECURITY= or
>     "security=" boot param.
>
> -   SELinux and AppArmor each can enable/disable themselves via
>     CONFIG_..._BOOTPARAM_VALUE= and selinux=/apparmor=.
>
>     So, right now, systems will have all the minor LSMs and integrity
>     initialized if they are built into the kernel without any way to
>     control their order or disable them at boot time. To select a major
>     LSM, the pattern is:
>
>     selinux=1 security=selinux
>
>     Note that both are used here because if you built with
>     CONFIG_SELINUX_BOOTPARAM_VALUE=0 and CONFIG_DEFAULT_SECURITY=apparmor,
>     just booting with "security=selinux" just disables AppArmor but
>     SELinux stays disabled. So the documented way to switch majors is with
>     "selinux=1 security=selinux". However Tomoyo and Smack do not have
>     separate enable/disable logic. They will work fine with just
>     "security=smack".
>
>     Now, in order to gain arbitrary LSM ordering, this series introduces
>     CONFIG_LSM= (to replace CONFIG_DEFAULT_SECURITY=) and "lsm=" (to
>     replace "security="). Note that "security=" has not been removed -- it
>     will still work. Mixing it with "lsm=" can lead to situations where
>     "security=" becomes effectively ignored, though.
>
>     In the rest of this I'm going to ignore capability: it will always be
>     first and it will always be enabled.
>
>     Assuming that all LSMs are built in (e.g. yama, loadpin, selinux,
>     smack, tomoyo, apparmor, integrity), here are the changes:
>
>     To choose the "default major LSM" of AppArmor before:
>     CONFIG_DEFAULT_SECURITY=apparmor
>
>     To choose the "default major LSM" of AppArmor without extreme stacking now:
>     CONFIG_LSM=yama,loadpin,integrity,apparmor
>
>     To choose the "default major LSM" of AppArmor with future extreme stacking now:
>     CONFIG_LSM=yama,loadpin,integrity,apparmor,tomoyo,selinux,smack
>
>     Whichever exclusive LSM is listed first will be the first to attempt
>     initialization. Any non-conflicting LSMs following it will initialize
>     too.
>
>     This means a distro can disable the "blob-sharing" behavior by just
>     providing a CONFIG_LSM= that includes a single major LSM.
>
>     To switch to SELinux at boot time with
>     "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>     work:
>
>     selinux=1 security=selinux
>
>     This will work still, since it will enable selinux (selinux=1) and
>     disable all other major LSMs (security=selinux).
>
>     The new way to enable selinux would be using
>     "lsm=yama,loadpin,integrity,selinux".
>

It seems to me that legacy way is more user friendly than the new one.
AppArmor and SElinux are households names but the rest may be enigmatic
for most users and the need for explicit passing them all may be
troublesome. Especially when the new ones like sara,landlock or cows :)
will be incoming. Moreover to knew what you have to pass there, you need
to look at CONFIG_LSM in kernel config (which will vary across distros
and also mean copy-paste from the web source may won't work as expected)
which again most users don't do.

I think there is risk that users will end up with "lsm=selinux" without
realizing that they may disable something along the way.

I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with
below assumptions:

I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme
stacking it will also remove the other major (explicit) lsm from it.

II. lsm="!$lsm" will remove "$lsm" from the string.

III. If "$lsm" already exist in the string, it's moved at the end of it
(this will cover ordering).

Examples:

1. Without extreme stacking.

a) Enable selinux, disable apparmor and leave the rest untouched.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux = yama,loadpin,integrity,selinux

b) Enable selinux, disable apparmor and disable loadpin.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,!loadpin = yama,integrity,selinux


2. With extreme stacking.

a) Enable selinux, disable apparmor and leave the rest untouched.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,!apparmor = yama,loadpin,integrity,selinux

b) Enable selinux, disable apparmor and disable loadpin.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,!apparmor,!loadpin = yama,integrity,selinux

c) Enable selinux and order it after apparmor.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux = yama,loadpin,integrity,apparmor,selinux

d) Enable selinux and order it before apparmor.

CONFIG_LSM=yama,loadpin,integrity,apparmor && lsm=selinux,apparmor = yama,loadpin,integrity,selinux,apparmor


IMO above will be easier to handle for users. At worst case with
full ordering all existing lsm's it will look the same as what
Kees proposes but I assume that ordering is rather for more
advanced people.

It's possible that something lime this was discussed already
but without full examples it was hard to me for tracking things.

Jordan

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Kees Cook]

On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
> On Thursday, October 11, 2018 7:57 PM, Kees Cook <keescook@chromium.org> wrote:
>>     To switch to SELinux at boot time with
>>     "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>>     work:
>>
>>     selinux=1 security=selinux
>>
>>     This will work still, since it will enable selinux (selinux=1) and
>>     disable all other major LSMs (security=selinux).
>>
>>     The new way to enable selinux would be using
>>     "lsm=yama,loadpin,integrity,selinux".
>>
>
> It seems to me that legacy way is more user friendly than the new one.
> AppArmor and SElinux are households names but the rest may be enigmatic
> for most users and the need for explicit passing them all may be
> troublesome. Especially when the new ones like sara,landlock or cows :)
> will be incoming. Moreover to knew what you have to pass there, you need
> to look at CONFIG_LSM in kernel config (which will vary across distros
> and also mean copy-paste from the web source may won't work as expected)
> which again most users don't do.
>
> I think there is risk that users will end up with "lsm=selinux" without
> realizing that they may disable something along the way.
>
> I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with
> below assumptions:
>
> I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme
> stacking it will also remove the other major (explicit) lsm from it.
>
> II. lsm="!$lsm" will remove "$lsm" from the string.
>
> III. If "$lsm" already exist in the string, it's moved at the end of it
> (this will cover ordering).

We've had things sort of like this proposed, but if you can convince
James and others, I'm all for it. I think the standing objection from
James and John about this is that the results of booting with
"lsm=something" ends up depending on CONFIG_LSM= for that distro. So
you end up with different behaviors instead of a consistent behavior
across all distros.

Now, in the future blob and extreme stacking world, having the
explicit lsm= list shouldn't be too bad since LSMs will effectively
ALL be initialized -- but they'll be inactive since they have no
policy loaded.

But I still agree with you: I'd like a friendlier way to
disable/enable specific LSMs, but an explicit lsm= seems to be the
only way.

> It's possible that something lime this was discussed already
> but without full examples it was hard to me for tracking things.

It's been a painful thread. ;)

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[John Johansen]

On 10/11/2018 04:09 PM, Kees Cook wrote:
> On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
> <Golden_Miller83@protonmail.ch> wrote:
>> On Thursday, October 11, 2018 7:57 PM, Kees Cook <keescook@chromium.org> wrote:
>>>     To switch to SELinux at boot time with
>>>     "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>>>     work:
>>>
>>>     selinux=1 security=selinux
>>>
>>>     This will work still, since it will enable selinux (selinux=1) and
>>>     disable all other major LSMs (security=selinux).
>>>
>>>     The new way to enable selinux would be using
>>>     "lsm=yama,loadpin,integrity,selinux".
>>>
>>
>> It seems to me that legacy way is more user friendly than the new one.
>> AppArmor and SElinux are households names but the rest may be enigmatic
>> for most users and the need for explicit passing them all may be
>> troublesome. Especially when the new ones like sara,landlock or cows :)
>> will be incoming. Moreover to knew what you have to pass there, you need
>> to look at CONFIG_LSM in kernel config (which will vary across distros
>> and also mean copy-paste from the web source may won't work as expected)
>> which again most users don't do.
>>
>> I think there is risk that users will end up with "lsm=selinux" without
>> realizing that they may disable something along the way.
>>
>> I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with
>> below assumptions:
>>
>> I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme
>> stacking it will also remove the other major (explicit) lsm from it.
>>
>> II. lsm="!$lsm" will remove "$lsm" from the string.
>>
>> III. If "$lsm" already exist in the string, it's moved at the end of it
>> (this will cover ordering).
> 
> We've had things sort of like this proposed, but if you can convince
> James and others, I'm all for it. I think the standing objection from
> James and John about this is that the results of booting with
> "lsm=something" ends up depending on CONFIG_LSM= for that distro. So
> you end up with different behaviors instead of a consistent behavior
> across all distros.
> 

Its certainly a point that could confuse the user. I do have concerns
about it, but not something that is on a must haves list

> Now, in the future blob and extreme stacking world, having the
> explicit lsm= list shouldn't be too bad since LSMs will effectively
> ALL be initialized -- but they'll be inactive since they have no
> policy loaded.
> 

you are more optimistic about this than I am, but there will be at
least some movement towards this.

> But I still agree with you: I'd like a friendlier way to
> disable/enable specific LSMs, but an explicit lsm= seems to be the
> only way.
> 

Hrmmm, I don't know about the only way, but a way to provide the
explicit list, and also set a specific set as the default in the
Kconfig is a hard requirement.

The initial lsm.ebable, lsm.disable had too many issues, and for
various reasons I never managed to get back to kees' proposal
for using +.

That said, I do think the right approach for the initial pass is
the explicit list. It moves the arguments to the side and allows
this work to move forward.

>> It's possible that something lime this was discussed already
>> but without full examples it was hard to me for tracking things.
> 
> It's been a painful thread. ;)
> 

Indeed

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Jordan Glover]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 1:48 AM, John Johansen <john.johansen@canonical.com> wrote:

> On 10/11/2018 04:09 PM, Kees Cook wrote:
>
> > On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
> > Golden_Miller83@protonmail.ch wrote:
> >
> > > On Thursday, October 11, 2018 7:57 PM, Kees Cook keescook@chromium.org wrote:
> > >
> > > >     To switch to SELinux at boot time with
> > > >     "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
> > > >     work:
> > > >
> > > >     selinux=1 security=selinux
> > > >
> > > >     This will work still, since it will enable selinux (selinux=1) and
> > > >     disable all other major LSMs (security=selinux).
> > > >
> > > >     The new way to enable selinux would be using
> > > >     "lsm=yama,loadpin,integrity,selinux".
> > > >
> > >
> > > It seems to me that legacy way is more user friendly than the new one.
> > > AppArmor and SElinux are households names but the rest may be enigmatic
> > > for most users and the need for explicit passing them all may be
> > > troublesome. Especially when the new ones like sara,landlock or cows :)
> > > will be incoming. Moreover to knew what you have to pass there, you need
> > > to look at CONFIG_LSM in kernel config (which will vary across distros
> > > and also mean copy-paste from the web source may won't work as expected)
> > > which again most users don't do.
> > > I think there is risk that users will end up with "lsm=selinux" without
> > > realizing that they may disable something along the way.
> > > I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with
> > > below assumptions:
> > > I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme
> > > stacking it will also remove the other major (explicit) lsm from it.
> > > II. lsm="!$lsm" will remove "$lsm" from the string.
> > > III. If "$lsm" already exist in the string, it's moved at the end of it
> > > (this will cover ordering).
> >
> > We've had things sort of like this proposed, but if you can convince
> > James and others, I'm all for it. I think the standing objection from
> > James and John about this is that the results of booting with
> > "lsm=something" ends up depending on CONFIG_LSM= for that distro. So
> > you end up with different behaviors instead of a consistent behavior
> > across all distros.
>
> Its certainly a point that could confuse the user. I do have concerns
> about it, but not something that is on a must haves list
>
> > Now, in the future blob and extreme stacking world, having the
> > explicit lsm= list shouldn't be too bad since LSMs will effectively
> > ALL be initialized -- but they'll be inactive since they have no
> > policy loaded.
>
> you are more optimistic about this than I am, but there will be at
> least some movement towards this.
>
> > But I still agree with you: I'd like a friendlier way to
> > disable/enable specific LSMs, but an explicit lsm= seems to be the
> > only way.
>
> Hrmmm, I don't know about the only way, but a way to provide the
> explicit list, and also set a specific set as the default in the
> Kconfig is a hard requirement.
>

My proposition allows for explicit "lsm=" list but also accepts non
explicit list. This is it's advantage above current approach.

The current approach works but it seems to target the very same people
who designed it :)

> The initial lsm.ebable, lsm.disable had too many issues, and for
> various reasons I never managed to get back to kees' proposal
> for using +.
>
> That said, I do think the right approach for the initial pass is
> the explicit list. It moves the arguments to the side and allows
> this work to move forward.
>

I'm afraid when it hits stable kernel and people will rely on it,
then it will be too late. Things will be even more hard to change
than now when we have to keep legacy syntax of security=xxx.

I added explanation why explicit list doesn't solve consistency
across distros in the other reply

> > > It's possible that something lime this was discussed already
> > > but without full examples it was hard to me for tracking things.
> >
> > It's been a painful thread. ;)
>
> Indeed

Jordan

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[John Johansen]

On 10/11/2018 05:11 PM, Jordan Glover wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, October 12, 2018 1:48 AM, John Johansen <john.johansen@canonical.com> wrote:
> 
>> On 10/11/2018 04:09 PM, Kees Cook wrote:
>>
>>> On Thu, Oct 11, 2018 at 3:58 PM, Jordan Glover
>>> Golden_Miller83@protonmail.ch wrote:
>>>
>>>> On Thursday, October 11, 2018 7:57 PM, Kees Cook keescook@chromium.org wrote:
>>>>
>>>>>     To switch to SELinux at boot time with
>>>>>     "CONFIG_LSM=yama,loadpin,integrity,apparmor", the old way continues to
>>>>>     work:
>>>>>
>>>>>     selinux=1 security=selinux
>>>>>
>>>>>     This will work still, since it will enable selinux (selinux=1) and
>>>>>     disable all other major LSMs (security=selinux).
>>>>>
>>>>>     The new way to enable selinux would be using
>>>>>     "lsm=yama,loadpin,integrity,selinux".
>>>>>
>>>>
>>>> It seems to me that legacy way is more user friendly than the new one.
>>>> AppArmor and SElinux are households names but the rest may be enigmatic
>>>> for most users and the need for explicit passing them all may be
>>>> troublesome. Especially when the new ones like sara,landlock or cows :)
>>>> will be incoming. Moreover to knew what you have to pass there, you need
>>>> to look at CONFIG_LSM in kernel config (which will vary across distros
>>>> and also mean copy-paste from the web source may won't work as expected)
>>>> which again most users don't do.
>>>> I think there is risk that users will end up with "lsm=selinux" without
>>>> realizing that they may disable something along the way.
>>>> I would prefer for "lsm=" to work as override to "CONFIG_LSM=" with
>>>> below assumptions:
>>>> I. lsm="$lsm" will append "$lsm" at the end of string. Before extreme
>>>> stacking it will also remove the other major (explicit) lsm from it.
>>>> II. lsm="!$lsm" will remove "$lsm" from the string.
>>>> III. If "$lsm" already exist in the string, it's moved at the end of it
>>>> (this will cover ordering).
>>>
>>> We've had things sort of like this proposed, but if you can convince
>>> James and others, I'm all for it. I think the standing objection from
>>> James and John about this is that the results of booting with
>>> "lsm=something" ends up depending on CONFIG_LSM= for that distro. So
>>> you end up with different behaviors instead of a consistent behavior
>>> across all distros.
>>
>> Its certainly a point that could confuse the user. I do have concerns
>> about it, but not something that is on a must haves list
>>
>>> Now, in the future blob and extreme stacking world, having the
>>> explicit lsm= list shouldn't be too bad since LSMs will effectively
>>> ALL be initialized -- but they'll be inactive since they have no
>>> policy loaded.
>>
>> you are more optimistic about this than I am, but there will be at
>> least some movement towards this.
>>
>>> But I still agree with you: I'd like a friendlier way to
>>> disable/enable specific LSMs, but an explicit lsm= seems to be the
>>> only way.
>>
>> Hrmmm, I don't know about the only way, but a way to provide the
>> explicit list, and also set a specific set as the default in the
>> Kconfig is a hard requirement.
>>
> 
> My proposition allows for explicit "lsm=" list but also accepts non
> explicit list. This is it's advantage above current approach.
> 
> The current approach works but it seems to target the very same people
> who designed it :)
> 
>> The initial lsm.ebable, lsm.disable had too many issues, and for
>> various reasons I never managed to get back to kees' proposal
>> for using +.
>>
>> That said, I do think the right approach for the initial pass is
>> the explicit list. It moves the arguments to the side and allows
>> this work to move forward.
>>
> 
> I'm afraid when it hits stable kernel and people will rely on it,
> then it will be too late. Things will be even more hard to change
> than now when we have to keep legacy syntax of security=xxx.
> 
> I added explanation why explicit list doesn't solve consistency
> across distros in the other reply
> 

It isn't perfect but it manages consistency across distros as best as
can be achieved atm.

Its just a fact that some LSMs are not going to be built into some
kernels. The only way to deal with that is direct people to build
their own kernels.

The other major problem is that the current LSM stacking patches do
not deal with "extreme" stacking. So doing

lsm=+apparmor

(I am going to stick with the + syntax atm to avoid confusion between
adding and setting)

assuming apparmor is builtin will not necessarily get you apparmor if
another major lsm is enabled.  Yes your specific proposal would as it
specifies it overrides the current major, except that ordering
important so if say landlock registers before apparmor, you may still
not get apparmor.

You proposal does not provide a means to ensure you have only a
specific set of LSMs enabled. As an LSM not explicitly listed in lsm=
lsm=! may still be enabled. So the user is going to have to be aware
of the initial LSMs list if they are trying to guarentee a specific
security arrangement.

This violates one of the hard asks, and I will tell you that this will
just mean there is going to be some distro patching to make sure it
exists.

The current explicit list is more consistent, and it is amenable to
being extended with + or ! as selective add/remove so we are not
locked into only supporting an explicit list.


>>>> It's possible that something lime this was discussed already
>>>> but without full examples it was hard to me for tracking things.
>>>
>>> It's been a painful thread. ;)
>>
>> Indeed
> 
> Jordan
> 

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Jordan Glover]

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 3:19 AM, John Johansen <john.johansen@canonical.com> wrote:
>
> It isn't perfect but it manages consistency across distros as best as
> can be achieved atm.
>
> Its just a fact that some LSMs are not going to be built into some
> kernels. The only way to deal with that is direct people to build
> their own kernels.
>
> The other major problem is that the current LSM stacking patches do
> not deal with "extreme" stacking. So doing
>
> lsm=+apparmor
>
> (I am going to stick with the + syntax atm to avoid confusion between
> adding and setting)
>
> assuming apparmor is builtin will not necessarily get you apparmor if
> another major lsm is enabled. Yes your specific proposal would as it
> specifies it overrides the current major, except that ordering
> important so if say landlock registers before apparmor, you may still
> not get apparmor.
>

I think this will be solved with LSM_ORDER_LAST or something like that
Kees proposed.

> You proposal does not provide a means to ensure you have only a
> specific set of LSMs enabled. As an LSM not explicitly listed in lsm=
> lsm=! may still be enabled. So the user is going to have to be aware
> of the initial LSMs list if they are trying to guarentee a specific
> security arrangement.
>

What about special marker like "!!" which will mean "this string is
explicit?

lsm=!!,apparmor

will enable apparmor and disable everything else.

lsm=!!,!apparmor or lsm=!!

will set the string empty and disable everything.

"!!" in "CONFIG_LSM" will take precedence over "!!" in "lsm=" which
will make "lsm=" totally ignored. This way distro could lock specific
lsm set which isn't possible with current approach.

CONFIG_LSM=!!,yama,loadpin,integrity,apparmor

> This violates one of the hard asks, and I will tell you that this will
> just mean there is going to be some distro patching to make sure it
> exists.
>

I think I can quess who will make those patches :)

> The current explicit list is more consistent, and it is amenable to
> being extended with + or ! as selective add/remove so we are not
> locked into only supporting an explicit list.
>

Jordan

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[John Johansen]

On 10/12/2018 04:31 AM, Jordan Glover wrote:
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, October 12, 2018 3:19 AM, John Johansen <john.johansen@canonical.com> wrote:
>>
>> It isn't perfect but it manages consistency across distros as best as
>> can be achieved atm.
>>
>> Its just a fact that some LSMs are not going to be built into some
>> kernels. The only way to deal with that is direct people to build
>> their own kernels.
>>
>> The other major problem is that the current LSM stacking patches do
>> not deal with "extreme" stacking. So doing
>>
>> lsm=+apparmor
>>
>> (I am going to stick with the + syntax atm to avoid confusion between
>> adding and setting)
>>
>> assuming apparmor is builtin will not necessarily get you apparmor if
>> another major lsm is enabled. Yes your specific proposal would as it
>> specifies it overrides the current major, except that ordering
>> important so if say landlock registers before apparmor, you may still
>> not get apparmor.
>>
> 
> I think this will be solved with LSM_ORDER_LAST or something like that
> Kees proposed.
> 
possibly, though that was proposed with a config patchset different than
the current proposal.

>> You proposal does not provide a means to ensure you have only a
>> specific set of LSMs enabled. As an LSM not explicitly listed in lsm=
>> lsm=! may still be enabled. So the user is going to have to be aware
>> of the initial LSMs list if they are trying to guarentee a specific
>> security arrangement.
>>
> 
> What about special marker like "!!" which will mean "this string is
> explicit?
> 
what about a special marker like "+" which means the string is addative
;)

> lsm=!!,apparmor
> 
> will enable apparmor and disable everything else.
> 
> lsm=!!,!apparmor or lsm=!!
> 
> will set the string empty and disable everything.
> 
> "!!" in "CONFIG_LSM" will take precedence over "!!" in "lsm=" which
> will make "lsm=" totally ignored. This way distro could lock specific
> lsm set which isn't possible with current approach.
> 
> CONFIG_LSM=!!,yama,loadpin,integrity,apparmor
> 
>> This violates one of the hard asks, and I will tell you that this will
>> just mean there is going to be some distro patching to make sure it
>> exists.
>>
> 
> I think I can quess who will make those patches :)
>

:)

Maybe but I am not the only one who is asking for it, and the majority of
the user bases I represent don't have this requirement. But with my distro
hat on it really is a requirement for a distro that wants to enable
users to have access to every lsm, but have a sane default set that
can be supported.

Its really not an insane security policy that new security measures
are vetted before they are enabled.

>> The current explicit list is more consistent, and it is amenable to
>> being extended with + or ! as selective add/remove so we are not
>> locked into only supporting an explicit list.
>>
> 
> Jordan
> 

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Kees Cook]

On Friday, October 12, 2018 3:19 AM, John Johansen
<john.johansen@canonical.com> wrote:
> It isn't perfect but it manages consistency across distros as best as
> can be achieved atm.

Yeah, this is why I'm okay with the current series: it provides as
consistent a view as possible, but leaves room for future improvements
(like adding "+" or "!" or "all" or whatever).

I'm curious to see what SELinux folks think of v5, though. I *think* I
addressed all the concerns there, even Paul's "I want my distro
default to not have extreme stacking" case too.

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Casey Schaufler]

On 10/12/2018 12:01 PM, Kees Cook wrote:
> On Friday, October 12, 2018 3:19 AM, John Johansen
> <john.johansen@canonical.com> wrote:
>> It isn't perfect but it manages consistency across distros as best as
>> can be achieved atm.
> Yeah, this is why I'm okay with the current series: it provides as
> consistent a view as possible, but leaves room for future improvements
> (like adding "+" or "!" or "all" or whatever).
>
> I'm curious to see what SELinux folks think of v5, though. I *think* I
> addressed all the concerns there, even Paul's "I want my distro
> default to not have extreme stacking" case too.
>
> -Kees

Looks like I should go on vacation more often. :)

I am generally opposed to fancy specification languages.
I support the explicit lsm= list specification because you
don't have to know any context to create a boot line that
will work, and be as close to what you've specified as possible
for the kernel configuration. One need look no further than
the mechanisms for setting POSIX ACLs for an example of
how to ensure a feature isn't used.

Had we the foresight to make security= take a list of
modules when Yama was added we might have avoided some of
this brouhaha, but there was no reason to expect that stacking
was ever going to happen back then.

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Kees Cook]

On Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 10/12/2018 12:01 PM, Kees Cook wrote:
>> On Friday, October 12, 2018 3:19 AM, John Johansen
>> <john.johansen@canonical.com> wrote:
>>> It isn't perfect but it manages consistency across distros as best as
>>> can be achieved atm.
>> Yeah, this is why I'm okay with the current series: it provides as
>> consistent a view as possible, but leaves room for future improvements
>> (like adding "+" or "!" or "all" or whatever).
>>
>> I'm curious to see what SELinux folks think of v5, though. I *think* I
>> addressed all the concerns there, even Paul's "I want my distro
>> default to not have extreme stacking" case too.
>>
>> -Kees
>
> Looks like I should go on vacation more often. :)
>
> I am generally opposed to fancy specification languages.
> I support the explicit lsm= list specification because you
> don't have to know any context to create a boot line that
> will work, and be as close to what you've specified as possible
> for the kernel configuration. One need look no further than
> the mechanisms for setting POSIX ACLs for an example of
> how to ensure a feature isn't used.
>
> Had we the foresight to make security= take a list of
> modules when Yama was added we might have avoided some of
> this brouhaha, but there was no reason to expect that stacking
> was ever going to happen back then.

This sounds like an "Ack" for you? :) I'll harass everyone in person
in a couple days.

Did you poke around at my combined series?
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Casey Schaufler]

On 10/23/2018 11:50 AM, Kees Cook wrote:
> On Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 10/12/2018 12:01 PM, Kees Cook wrote:
>>> On Friday, October 12, 2018 3:19 AM, John Johansen
>>> <john.johansen@canonical.com> wrote:
>>>> It isn't perfect but it manages consistency across distros as best as
>>>> can be achieved atm.
>>> Yeah, this is why I'm okay with the current series: it provides as
>>> consistent a view as possible, but leaves room for future improvements
>>> (like adding "+" or "!" or "all" or whatever).
>>>
>>> I'm curious to see what SELinux folks think of v5, though. I *think* I
>>> addressed all the concerns there, even Paul's "I want my distro
>>> default to not have extreme stacking" case too.
>>>
>>> -Kees
>> Looks like I should go on vacation more often. :)
>>
>> I am generally opposed to fancy specification languages.
>> I support the explicit lsm= list specification because you
>> don't have to know any context to create a boot line that
>> will work, and be as close to what you've specified as possible
>> for the kernel configuration. One need look no further than
>> the mechanisms for setting POSIX ACLs for an example of
>> how to ensure a feature isn't used.
>>
>> Had we the foresight to make security= take a list of
>> modules when Yama was added we might have avoided some of
>> this brouhaha, but there was no reason to expect that stacking
>> was ever going to happen back then.
> This sounds like an "Ack" for you? :) I'll harass everyone in person
> in a couple days.

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

> Did you poke around at my combined series?
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing

I hope to do that on the plane later today.

> -Kees

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Casey Schaufler]

On 10/23/2018 12:05 PM, Casey Schaufler wrote:
> On 10/23/2018 11:50 AM, Kees Cook wrote:
>
>> Did you poke around at my combined series?
>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing
> I hope to do that on the plane later today.

I had a chance to poke at the combined series and it
all seems to work as advertised. 

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Kees Cook]

On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 10/23/2018 12:05 PM, Casey Schaufler wrote:
>> On 10/23/2018 11:50 AM, Kees Cook wrote:
>>
>>> Did you poke around at my combined series?
>>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing
>> I hope to do that on the plane later today.
>
> I had a chance to poke at the combined series and it
> all seems to work as advertised.

/me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;)

-Kees

-- 
Kees Cook

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Casey Schaufler]

On 10/24/2018 1:12 PM, Kees Cook wrote:
> On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 10/23/2018 12:05 PM, Casey Schaufler wrote:
>>> On 10/23/2018 11:50 AM, Kees Cook wrote:
>>>
>>>> Did you poke around at my combined series?
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing
>>> I hope to do that on the plane later today.
>> I had a chance to poke at the combined series and it
>> all seems to work as advertised.
> /me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;)
>
> -Kees
>
Now that we have next-general updated I'm porting these forward.

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Casey Schaufler]

On 11/14/2018 1:04 PM, Casey Schaufler wrote:
> On 10/24/2018 1:12 PM, Kees Cook wrote:
>> On Wed, Oct 24, 2018 at 1:56 AM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>>> On 10/23/2018 12:05 PM, Casey Schaufler wrote:
>>>> On 10/23/2018 11:50 AM, Kees Cook wrote:
>>>>
>>>>> Did you poke around at my combined series?
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing
>>>> I hope to do that on the plane later today.
>>> I had a chance to poke at the combined series and it
>>> all seems to work as advertised.
>> /me stares at John, Paul, and Stephen. Hurry up and get off your planes! ;)
>>
>> -Kees
>>
> Now that we have next-general updated I'm porting these forward.

I have ported Kees' set forward to 4.20-rc2:
	https://github.com/cschaufler/lsm-stacking.git#after-kees-4.20-rc2

There's one bug fix in ordered_lsm_parse() but otherwise just mechanical.

The infrastructure blob management required for TOMOYO, Landlock
and SARA is available:
	https://github.com/cschaufler/lsm-stacking.git#blobs-4.20-rc2

There's nothing new here, although I had to make a few changes to
account for Kees' changes in the preceding patches. I will post the
patches shortly.

The full stacking changes based on this are still in the works. Netfilter
has added a whole new use of secmarks and I'm working to make the individual
patches smaller for easier review.

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Jordan Glover]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 1:09 AM, Kees Cook <keescook@chromium.org> wrote:

> We've had things sort of like this proposed, but if you can convince
> James and others, I'm all for it. I think the standing objection from
> James and John about this is that the results of booting with
> "lsm=something" ends up depending on CONFIG_LSM= for that distro. So
> you end up with different behaviors instead of a consistent behavior
> across all distros.
>

Ok, I'll try :)

The final lsm string contains two parts: Kconfig "CONFIG_LSM=" and boot
param "lsm=". Changing even only one of those parts also changes the
final string.

In case of distros, it's the "CONFIG_LSM=" which changes. Even when "lsm="
stays constant, the behavior will be different, example:

Distro A has: CONFIG_LSM=loadpin,integrity,selinux
Distro B has CONFIG_LSM=yama,loadpin,integrity,selinux

User on distro A wants to enable apparmor with:

lsm=loadpin,integrity,apparmor

which they do and add it to howto on wiki.

User on distro B want to enable apparmor, they found info on some wiki and do:

lsm=loadpin,integrity,apparmor


Puff, yama got disabled!

Above example shows why I think "consistent behavior across all distros"
argument for current approach is flawed -  because distros aren't
consistent. In my proposition the user will just use "lsm=apparmor" and
it will consistently enable apparmor on all distros which is what they
really wanted, but all pre-existing differences across distros will
remain unchanged.

The current approach requires that everyone who dares to touch "lsm="
knows about existence of all lsm, their enabled/disabled status on
target distro and their order. I doubt there are many people other
than recipients of this mail who fit for the above.

I it's better to assume that average user has rather vague knowledge
about lsm and don't delve deep into Kconfig's of their chosen distro.
If they want to use "lsm=" their goal is to disable/enable on or more
things. My proposition will work better for those. More advanced users
still will may pass any "lsm=" string as they like, this having full
control.

Jordan

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[John Johansen]

On 10/11/2018 04:53 PM, Jordan Glover wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, October 12, 2018 1:09 AM, Kees Cook <keescook@chromium.org> wrote:
> 
>> We've had things sort of like this proposed, but if you can convince
>> James and others, I'm all for it. I think the standing objection from
>> James and John about this is that the results of booting with
>> "lsm=something" ends up depending on CONFIG_LSM= for that distro. So
>> you end up with different behaviors instead of a consistent behavior
>> across all distros.
>>
> 
> Ok, I'll try :)
> 
> The final lsm string contains two parts: Kconfig "CONFIG_LSM=" and boot
> param "lsm=". Changing even only one of those parts also changes the
> final string.
> 
> In case of distros, it's the "CONFIG_LSM=" which changes. Even when "lsm="
> stays constant, the behavior will be different, example:
> 
> Distro A has: CONFIG_LSM=loadpin,integrity,selinux
> Distro B has CONFIG_LSM=yama,loadpin,integrity,selinux
> 
> User on distro A wants to enable apparmor with:
> 
> lsm=loadpin,integrity,apparmor
> 
> which they do and add it to howto on wiki.
> 
> User on distro B want to enable apparmor, they found info on some wiki and do:
> 
> lsm=loadpin,integrity,apparmor
> 
> 
> Puff, yama got disabled!
> 
> Above example shows why I think "consistent behavior across all distros"
> argument for current approach is flawed -  because distros aren't
> consistent. In my proposition the user will just use "lsm=apparmor" and
> it will consistently enable apparmor on all distros which is what they
> really wanted, but all pre-existing differences across distros will
> remain unchanged.

Are you sure about that? I have had more than one question about
security=X resulting in a system with more than just X enabled. Ie why
is yama enabled when I specifically set security to X.

There will certainly be cases where what you describe is exactly what
the user wants. The problem is an explosion of options isn't good
for the user either.

What I want at the moment is the discussion about different ways to
enable LSMs to be split off so this work can move forward.

> 
> The current approach requires that everyone who dares to touch "lsm="
> knows about existence of all lsm, their enabled/disabled status on
> target distro and their order. I doubt there are many people other
> than recipients of this mail who fit for the above.
> 
Without having gotten a chance to review the current set of patches
that was not what was discussed, it should only requires they know the
set that they want.

It is possible some of the LSMs in the list are not available for a
given kernel, but that is a problem with even the additive approach.
That is
  lsm=+apparmor

will not add apparmor to the set of LSMs available at run time if
apparmor has not been built into the kernel.


> I it's better to assume that average user has rather vague knowledge
> about lsm and don't delve deep into Kconfig's of their chosen distro.
> If they want to use "lsm=" their goal is to disable/enable on or more
> things. My proposition will work better for those. More advanced users
> still will may pass any "lsm=" string as they like, this having full
> control.
> 
> Jordan
> 

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[Jordan Glover]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 2:26 AM, John Johansen <john.johansen@canonical.com> wrote:

> On 10/11/2018 04:53 PM, Jordan Glover wrote:
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Friday, October 12, 2018 1:09 AM, Kees Cook keescook@chromium.org wrote:
> >
> > > We've had things sort of like this proposed, but if you can convince
> > > James and others, I'm all for it. I think the standing objection from
> > > James and John about this is that the results of booting with
> > > "lsm=something" ends up depending on CONFIG_LSM= for that distro. So
> > > you end up with different behaviors instead of a consistent behavior
> > > across all distros.
> >
> > Ok, I'll try :)
> > The final lsm string contains two parts: Kconfig "CONFIG_LSM=" and boot
> > param "lsm=". Changing even only one of those parts also changes the
> > final string.
> > In case of distros, it's the "CONFIG_LSM=" which changes. Even when "lsm="
> > stays constant, the behavior will be different, example:
> > Distro A has: CONFIG_LSM=loadpin,integrity,selinux
> > Distro B has CONFIG_LSM=yama,loadpin,integrity,selinux
> > User on distro A wants to enable apparmor with:
> > lsm=loadpin,integrity,apparmor
> > which they do and add it to howto on wiki.
> > User on distro B want to enable apparmor, they found info on some wiki and do:
> > lsm=loadpin,integrity,apparmor
> > Puff, yama got disabled!
> > Above example shows why I think "consistent behavior across all distros"
> > argument for current approach is flawed - because distros aren't
> > consistent. In my proposition the user will just use "lsm=apparmor" and
> > it will consistently enable apparmor on all distros which is what they
> > really wanted, but all pre-existing differences across distros will
> > remain unchanged.
>
> Are you sure about that? I have had more than one question about
> security=X resulting in a system with more than just X enabled. Ie why
> is yama enabled when I specifically set security to X.
>

So, non-explicit list will match current "security=" behavior which users
are more familiar with. The current answer for this question is "because
your distro enabled it and you didn't disabled it. With non-explcit list
that answer will stay the same.

With explicit list, the question will be "why is yama disabled when I
enabled AppArmor with lsm=apparmor".

To ask both questions user have to know that something like "yama" exist
in first place.

As for question what users typically want you may look at search results
for "disable/enable yama" and "disable/enable apparmor/selinux". The
difference is several orders of magnitude. That's why I think typical user
just want to switch on/off one major lsm. I don't think anecdotal evidence
is representative here.

> There will certainly be cases where what you describe is exactly what
> the user wants. The problem is an explosion of options isn't good
> for the user either.
>
> What I want at the moment is the discussion about different ways to
> enable LSMs to be split off so this work can move forward.
>
> > The current approach requires that everyone who dares to touch "lsm="
> > knows about existence of all lsm, their enabled/disabled status on
> > target distro and their order. I doubt there are many people other
> > than recipients of this mail who fit for the above.
>
> Without having gotten a chance to review the current set of patches
> that was not what was discussed, it should only requires they know the
> set that they want.
>

"it should only requires they know the set that they want" is very
hard requirement and I don't think most users will pass this.
Especially when sets like:

lsm=yama,loadpin,integrity,apparmor
lsm=loadpin,integrity,yama,apparmor

will behave differently.

Jordan

Re: [PATCH security-next v5 00/30] LSM: Explict ordering

[John Johansen]

On 10/12/2018 04:31 AM, Jordan Glover wrote:
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, October 12, 2018 2:26 AM, John Johansen <john.johansen@canonical.com> wrote:
> 
>> On 10/11/2018 04:53 PM, Jordan Glover wrote:
>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Friday, October 12, 2018 1:09 AM, Kees Cook keescook@chromium.org wrote:
>>>
>>>> We've had things sort of like this proposed, but if you can convince
>>>> James and others, I'm all for it. I think the standing objection from
>>>> James and John about this is that the results of booting with
>>>> "lsm=something" ends up depending on CONFIG_LSM= for that distro. So
>>>> you end up with different behaviors instead of a consistent behavior
>>>> across all distros.
>>>
>>> Ok, I'll try :)
>>> The final lsm string contains two parts: Kconfig "CONFIG_LSM=" and boot
>>> param "lsm=". Changing even only one of those parts also changes the
>>> final string.
>>> In case of distros, it's the "CONFIG_LSM=" which changes. Even when "lsm="
>>> stays constant, the behavior will be different, example:
>>> Distro A has: CONFIG_LSM=loadpin,integrity,selinux
>>> Distro B has CONFIG_LSM=yama,loadpin,integrity,selinux
>>> User on distro A wants to enable apparmor with:
>>> lsm=loadpin,integrity,apparmor
>>> which they do and add it to howto on wiki.
>>> User on distro B want to enable apparmor, they found info on some wiki and do:
>>> lsm=loadpin,integrity,apparmor
>>> Puff, yama got disabled!
>>> Above example shows why I think "consistent behavior across all distros"
>>> argument for current approach is flawed - because distros aren't
>>> consistent. In my proposition the user will just use "lsm=apparmor" and
>>> it will consistently enable apparmor on all distros which is what they
>>> really wanted, but all pre-existing differences across distros will
>>> remain unchanged.
>>
>> Are you sure about that? I have had more than one question about
>> security=X resulting in a system with more than just X enabled. Ie why
>> is yama enabled when I specifically set security to X.
>>
> 
> So, non-explicit list will match current "security=" behavior which users
> are more familiar with. The current answer for this question is "because
> your distro enabled it and you didn't disabled it. With non-explcit list
> that answer will stay the same.
> 

the current behavior is problematic leads to a configuration nightmare, 
and is the reason lsm= is proposed instead of just sticking with
security=

> With explicit list, the question will be "why is yama disabled when I
> enabled AppArmor with lsm=apparmor".
> 
yes that will happen as well

> To ask both questions user have to know that something like "yama" exist
> in first place.
> 
yes. However when it comes to security I don't think its too insane to
want to vet new modules before they become part of your configuration.
This is something distros want to be able to do and something some users
want.

I am not claiming this is what all users will want, and it certainly
isn't the best situation for the adoption of new lsms. But is a very
understandable security policy stance.

> As for question what users typically want you may look at search results
> for "disable/enable yama" and "disable/enable apparmor/selinux". The
> difference is several orders of magnitude. That's why I think typical user
> just want to switch on/off one major lsm. I don't think anecdotal evidence
> is representative here.
> 
>> There will certainly be cases where what you describe is exactly what
>> the user wants. The problem is an explosion of options isn't good
>> for the user either.
>>
>> What I want at the moment is the discussion about different ways to
>> enable LSMs to be split off so this work can move forward.
>>
>>> The current approach requires that everyone who dares to touch "lsm="
>>> knows about existence of all lsm, their enabled/disabled status on
>>> target distro and their order. I doubt there are many people other
>>> than recipients of this mail who fit for the above.
>>
>> Without having gotten a chance to review the current set of patches
>> that was not what was discussed, it should only requires they know the
>> set that they want.
>>
> 
> "it should only requires they know the set that they want" is very
> hard requirement and I don't think most users will pass this.
> Especially when sets like:
> 
> lsm=yama,loadpin,integrity,apparmor
> lsm=loadpin,integrity,yama,apparmor
> 
> will behave differently.
> 
yes, that is a problem and it highlights the complexity of the problem
we are dealing with.

Your proposal tries to hide the ordering issues from the user but they
still suffer from the potentially different behavior of list ordering
as it is moving the lsm around in the list.

fwiw kees finally convinced me that having the order set separate from
enablement in the kconfig is better for the user because of problems
like this.