From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from namei.org ([65.99.196.166]:58810 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728232AbeIMCgS (ORCPT ); Wed, 12 Sep 2018 22:36:18 -0400 Date: Thu, 13 Sep 2018 07:29:32 +1000 (AEST) From: James Morris To: Casey Schaufler , Salvatore Mesoraca , mic@digikod.net cc: LSM , LKLM , SE Linux , John Johansen , Kees Cook , Tetsuo Handa , Paul Moore , Stephen Smalley , "linux-fsdevel@vger.kernel.org" , Alexey Dobriyan , "Schaufler, Casey" Subject: Re: [PATCH v2 00/10] LSM: Module stacking in support of S.A.R.A and Landlock In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1665246916-734686802-1536787774=:19741" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1665246916-734686802-1536787774=:19741 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Adding the SARA and LandLock authors for review & comment. Salvatore & Mickaël: does this patchset meet your needs for merging to mainline? On Tue, 11 Sep 2018, Casey Schaufler wrote: > LSM: Module stacking in support of S.A.R.A and Landlock > > v2: Reduce the patchset to what is required to support > the proposed S.A.R.A. and LandLock security modules > > The S.A.R.A. security module is intended to be used > in conjunction with other security modules. It requires > state to be maintained for the credential, which > in turn requires a mechanism for sharing the credential > security blob. The module also requires mechanism for > user space manipulation of the credential information, > hence an additional subdirectory in /proc/.../attr. > > The LandLock security module provides user configurable > policy in the secmark mechanism. It requires data in > the credential, file and inode security blobs. For this > to be used along side the existing "major" security > modules mechanism for sharing these blobs is provided. > > A side effect of providing sharing of the crendential > security blob is that the TOMOYO module can be used at > the same time as the other "major" modules. > > The mechanism for configuring which security modules are > enabled has to change when stacking in enabled. Any > module that uses just the security blobs that are shared > can be selected. Additionally, one other "major" module > can be selected. > > The security module stacking issues around networking and > IPC are not addressed here as they are beyond what is > required for TOMOYO, S.A.R.A and LandLock. > > git://github.com/cschaufler/lsm-stacking.git#stacking-4.19-rc2-saralock > > Signed-off-by: Casey Schaufler > --- > Documentation/admin-guide/LSM/index.rst | 23 ++- > fs/proc/base.c | 64 ++++++- > fs/proc/internal.h | 1 + > include/linux/lsm_hooks.h | 20 ++- > include/linux/security.h | 15 +- > kernel/cred.c | 13 -- > security/Kconfig | 92 ++++++++++ > security/apparmor/domain.c | 2 +- > security/apparmor/include/cred.h | 24 ++- > security/apparmor/include/file.h | 9 +- > security/apparmor/include/lib.h | 4 + > security/apparmor/lsm.c | 53 ++++-- > security/apparmor/task.c | 6 +- > security/security.c | 293 ++++++++++++++++++++++++++++++-- > security/selinux/hooks.c | 215 ++++++++--------------- > security/selinux/include/objsec.h | 37 +++- > security/selinux/selinuxfs.c | 5 +- > security/selinux/xfrm.c | 4 +- > security/smack/smack.h | 42 ++++- > security/smack/smack_access.c | 4 +- > security/smack/smack_lsm.c | 283 +++++++++++------------------- > security/smack/smackfs.c | 18 +- > security/tomoyo/common.h | 31 +++- > security/tomoyo/domain.c | 4 +- > security/tomoyo/securityfs_if.c | 15 +- > security/tomoyo/tomoyo.c | 57 +++++-- > 26 files changed, 899 insertions(+), 435 deletions(-) > -- James Morris --1665246916-734686802-1536787774=:19741--