LSM: Stacking for major security modules - resend
From: | Casey Schaufler <casey-AT-schaufler-ca.com> | |
To: | LSM <linux-security-module-AT-vger.kernel.org> | |
Subject: | [PATCH RFC 0/9] LSM: Stacking for major security modules - resend | |
Date: | Wed, 25 Jan 2017 17:32:14 -0800 | |
Message-ID: | <bdd17661-5f1f-833f-1e68-887b288616bb@schaufler-ca.com> | |
Cc: | James Morris <jmorris-AT-namei.org>, John Johansen <john.johansen-AT-canonical.com>, Tetsuo Handa <penguin-kernel-AT-i-love.sakura.ne.jp>, Paul Moore <paul-AT-paul-moore.com>, Stephen Smalley <sds-AT-tycho.nsa.gov>, Kees Cook <keescook-AT-chromium.org>, Casey Schaufler <casey-AT-schaufler-ca.com> |
Subject: [PATCH RFC 0/9] LSM: Stacking for major security modules - resend I am sending this as an RFC as there are still issue to resolve around memory management and at least one known issue with the way mount options are handled. If you stop at patch 5 you can use any combination of modules so long as you use only one of SELinux and Smack. Patches 6-9 take you most of the way to complete stacking, but cannot be said to completely address all the issues. This patch set implements stacking for "major" security modules that use cred and file blobs. Management of security blobs is moved from the security modules and into the LSM infrastructure. This has been proposed in the past by Serge Hallyn and David Howells. This implementation owes much to their work. The bulk of the change is in abstracting use of blobs within the security modules. This allows the modules to share a single blob and hides the details from the code. There is Modules are required to declare the amount of space they require for each blob they use. Because modules deal with blobs during their initialization the blob sizes must be declared prior to module initialization. The module initialization becomes a two step process. Security module stacking is optional. If stacking is not configured, the CONFIG_DEFAULT_SECURITY value is used, just as before. If stacking is configured using CONFIG_SECURITY_STACKING the modules desired for the stack are selected individually. AppArmor would be selected by specifying CONFIG_SECURITY_APPARMOR_STACKED. The CONFIG_DEFAULT_SECURITY is ignored. The security= boot option is still respected and has the same behavior as before, allowing a single module to be used instead of the specified stack. To accommodate multiple active modules a security "context" is defined to use a regular format: lsmname='lsmvalue'[,lsmname='lsmvalue']... This is not supported by any existing user space run time code. I have tested these patches in various configurations of Ubuntu and Fedora. I have had much better success with SELinux in permissive mode than enforcing, but that appears to be a result of user space code issues. Smack and SELinux together have limited success, again because of the context format. Patch 1 Introduces /sys/fs/security/lsm and is in security-next Patch 2 Adds a smack subdirectory in /proc/.../attr (proposed separately) Patch 3 Move management of the cred blob to the LSM infrastructure. Patch 4 Move management of the file blob to the LSM infrastructure. Patch 5 Change how the security modules get selected. Patch 6 Complete the move to LSM infrastructure blob management. Patch 7 Support mount options for multiple security modules. Patch 8 Change secids from a u32 to a structure. Patch 9 Allow explicit configuration of netlabel in SELinux These patches can be found in git at: https://github.com/cschaufler/smack-next.git#stacking-4.1... Signed-off-by: Casey Schaufler <casey@schaufler-ca.com> --- Documentation/security/LSM.txt | 40 +- drivers/usb/core/devio.c | 13 +- fs/btrfs/super.c | 10 +- fs/proc/base.c | 95 ++- fs/proc/internal.h | 1 + fs/xattr.c | 6 +- include/linux/audit.h | 10 +- include/linux/cred.h | 3 +- include/linux/lsm_hooks.h | 105 +++- include/linux/sched.h | 3 +- include/linux/security.h | 227 ++++++-- include/net/flow.h | 5 +- include/net/netlabel.h | 8 +- include/net/scm.h | 4 +- kernel/audit.c | 25 +- kernel/audit.h | 9 +- kernel/auditfilter.c | 4 +- kernel/auditsc.c | 42 +- kernel/cred.c | 19 +- kernel/signal.c | 6 +- net/ipv4/cipso_ipv4.c | 5 +- net/ipv4/ip_sockglue.c | 6 +- net/netfilter/nf_conntrack_netlink.c | 12 +- net/netfilter/nf_conntrack_standalone.c | 6 +- net/netfilter/nfnetlink_queue.c | 9 +- net/netfilter/xt_AUDIT.c | 9 +- net/netfilter/xt_SECMARK.c | 6 +- net/netlabel/netlabel_kapi.c | 2 +- net/netlabel/netlabel_unlabeled.c | 30 +- net/netlabel/netlabel_unlabeled.h | 2 +- net/netlabel/netlabel_user.c | 4 +- net/unix/af_unix.c | 6 +- net/xfrm/xfrm_policy.c | 6 +- net/xfrm/xfrm_state.c | 3 +- security/Kconfig | 86 +++ security/apparmor/context.c | 2 - security/apparmor/include/context.h | 26 +- security/apparmor/lsm.c | 130 +++-- security/commoncap.c | 3 +- security/inode.c | 26 +- security/integrity/ima/ima_policy.c | 7 +- security/loadpin/loadpin.c | 2 +- security/security.c | 995 ++++++++++++++++++++++++++++++-- security/selinux/Kconfig | 12 + security/selinux/Makefile | 2 +- security/selinux/hooks.c | 718 ++++++++++------------- security/selinux/include/audit.h | 2 +- security/selinux/include/netlabel.h | 4 +- security/selinux/include/objsec.h | 89 ++- security/selinux/include/security.h | 4 +- security/selinux/include/xfrm.h | 9 +- security/selinux/netlabel.c | 17 +- security/selinux/selinuxfs.c | 7 +- security/selinux/ss/ebitmap.c | 4 +- security/selinux/ss/ebitmap.h | 2 +- security/selinux/ss/mls.c | 4 +- security/selinux/ss/mls.h | 2 +- security/selinux/ss/services.c | 17 +- security/selinux/xfrm.c | 29 +- security/smack/smack.h | 95 ++- security/smack/smack_access.c | 2 +- security/smack/smack_lsm.c | 736 ++++++++++------------- security/smack/smack_netfilter.c | 28 +- security/smack/smackfs.c | 28 +- security/tomoyo/common.h | 25 +- security/tomoyo/domain.c | 4 +- security/tomoyo/securityfs_if.c | 13 +- security/tomoyo/tomoyo.c | 58 +- security/yama/yama_lsm.c | 2 +- 69 files changed, 2642 insertions(+), 1289 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html