Messages in this thread | | | Date | Sat, 02 May 2015 14:44:25 -0700 | From | Casey Schaufler <> | Subject | [PATCH 0/7 v22] LSM: Multiple concurrent LSMs |
| |
Subject: [PATCH 0/7 v22] 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.1-rc1. A git tree will be available shortly at:
git@github.com:cschaufler/smack-next.git#stacking-v22
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
--- include/linux/lsm_hooks.h | 1886 ++++++++++++++++++++++++++++++++++++++++++++ include/linux/security.h | 1621 +------------------------------------ security/Makefile | 2 +- security/apparmor/domain.c | 12 +- security/apparmor/lsm.c | 131 ++- security/capability.c | 1158 --------------------------- security/commoncap.c | 41 +- security/security.c | 955 +++++++++++++++------- security/selinux/hooks.c | 490 +++++------- security/smack/smack.h | 4 +- security/smack/smack_lsm.c | 307 ++++--- security/smack/smackfs.c | 2 +- security/tomoyo/tomoyo.c | 72 +- security/yama/yama_lsm.c | 60 +- 14 files changed, 3064 insertions(+), 3677 deletions(-)
| |