On Tue, Jun 18, 2019 at 09:52:44PM -0700, Kees Cook wrote:

On Tue, Jun 18, 2019 at 04:05:30PM -0700, Casey Schaufler wrote:

quoted

When more than one security module is exporting data to
audit and networking sub-systems a single 32 bit integer
is no longer sufficient to represent the data. Add a
structure to be used instead.

The lsmblob structure is currently an array of
u32 "secids". There is an entry for each of the
security modules built into the system that would
use secids if active. The system assigns the module
a "slot" when it registers hooks. If modules are
compiled in but not registered there will be unused
slots.

Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
---
 include/linux/lsm_hooks.h |  1 +
 include/linux/security.h  | 62 +++++++++++++++++++++++++++++++++++++++
 security/security.c       | 31 ++++++++++++++++++++
 3 files changed, 94 insertions(+)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 3fe39abccc8f..4d1ddf1a2aa6 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h

@@ -2038,6 +2038,7 @@ struct security_hook_list {
 	struct hlist_head		*head;
 	union security_list_options	hook;
 	char				*lsm;
+	int				slot;
 } __randomize_layout;

Hm, this feels redundant (as does the existing "char *lsm") now that we
have lsm_info. The place for assigned-at-init value is blob_sizes, which
hangs off of lsm_info (as does the LSM char *)...

Hm, nevermind. lsm_info is __initdata. I will ponder a way to refactor
this in the future. For now, just leave slot in here with char *lsm.

-- 
Kees Cook