Message-ID: <54FE4553.3000209@schaufler-ca.com>
Date:	Mon, 09 Mar 2015 18:13:55 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	James Morris <jmorris@...ei.org>,
	James Morris <james.l.morris@...cle.com>,
	LSM <linux-security-module@...r.kernel.org>,
	LKLM <linux-kernel@...r.kernel.org>
CC:	Paul Moore <pmoore@...hat.com>,
	John Johansen <john.johansen@...onical.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Stephen Smalley <sds@...ho.nsa.gov>,
	Eric Paris <eparis@...hat.com>,
	Kees Cook <keescook@...omium.org>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: [PATCH 0/7 v21] LSM: Multiple concurrent LSMs

Subject: [PATCH 0/7 v21] LSM: Multiple concurrent LSMs

Replace the current ad hoc stacking of the capabilities
and Yama security modules with a generalized stacking scheme. 

The old structure had a single set of module hooks contained
in a security_operations structure. This structure was initialized
with a set of stubs referred to as the "capabilities" module.
In fact only a few of these hooks actually did anything useful.
When a module replaced the capabilities module the entries
supplied replaced those from the capabilities module. The
new hook was expected to call the replaced capability code
if "stacking" was desired, which it usually was. Yama stacking
is done by ifdefs in the security infrastructure.

The new structure provides a list of module hooks for each
interface. The non-trivial functions from the capabilities
module are add to the list first. If Yama stacking is configured
the Yama functions are added next. If a module is specified as
the "default" module, or is specified on the command line, it
is added next.

Functions are called in the order added to the list. The
security interfaces stop when a function indicates an access
denial. It is possible for a list to be empty. That is treated
as a success in most cases.

Each security module provides an array of function list entries.
This is initialized with the information needed to properly add
the entries to the function lists.

The sheer size of this patch set is somewhat frightening. This
is an artifact of the number of security interfaces involved and
except for a few cases the changes are mechanical in nature.
Except for the removal of some information specific to the security
module infrastructure itself, the change is transparent to the rest
of the kernel.

This is going to break out-of-tree security modules. It's easy to
update a module to the new scheme, and I'd be happy to do it for
any module I know about, but if it isn't in the tree, I don't know
about it.

The stacking of modules that use the security blob pointers
cred->security, inode->i_security, etc has not been addressed.
That is future work with a delightful set of issues. 

This patch set is based on James Morris' security-next tree,
which is itself based on Linus' 4.0-rc1. It reflects the 11
patches of v20.

Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
---
 include/linux/lsm_hooks.h  | 1872 ++++++++++++++++++++++++++++++++++++++++++++
 include/linux/security.h   | 1613 +-------------------------------------
 security/Makefile          |    2 +-
 security/apparmor/domain.c |    4 +-
 security/apparmor/lsm.c    |  131 ++--
 security/capability.c      | 1164 ---------------------------
 security/commoncap.c       |   36 +-
 security/security.c        |  979 ++++++++++++++++-------
 security/selinux/hooks.c   |  477 +++++------
 security/smack/smack.h     |    4 +-
 security/smack/smack_lsm.c |  305 ++++----
 security/smack/smackfs.c   |    2 +-
 security/tomoyo/tomoyo.c   |   72 +-
 security/yama/yama_lsm.c   |   60 +-
 14 files changed, 3071 insertions(+), 3650 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists