From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f193.google.com ([209.85.208.193]:38058 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727006AbeIMS0T (ORCPT ); Thu, 13 Sep 2018 14:26:19 -0400 Received: by mail-lj1-f193.google.com with SMTP id p6-v6so4573177ljc.5 for ; Thu, 13 Sep 2018 06:16:51 -0700 (PDT) MIME-Version: 1.0 References: <99cb1ae7-8881-eb9a-a8cb-a787abe454e1@schaufler-ca.com> In-Reply-To: From: Paul Moore Date: Thu, 13 Sep 2018 09:16:39 -0400 Message-ID: Subject: Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock To: keescook@chromium.org Cc: casey@schaufler-ca.com, linux-security-module@vger.kernel.org, James Morris , linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp, Stephen Smalley , linux-fsdevel@vger.kernel.org, adobriyan@gmail.com, casey.schaufler@intel.com Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Sep 13, 2018 at 12:19 AM Kees Cook wrote: > On Tue, Sep 11, 2018 at 9:42 AM, Casey Schaufler wrote: > > Two proposed security modules require the ability to > > share security blobs with existing "major" security modules. > > These modules, S.A.R.A and LandLock, provide significantly > > different services than SELinux, Smack or AppArmor. Using > > either in conjunction with the existing modules is quite > > reasonable. S.A.R.A requires access to the cred blob, while > > LandLock uses the cred, file and inode blobs. > > > > The use of the cred, file and inode blobs has been > > abstracted in preceding patches in the series. This > > patch teaches the affected security modules how to access > > the part of the blob set aside for their use in the case > > where blobs are shared. The configuration option > > CONFIG_SECURITY_STACKING identifies systems where the > > blobs may be shared. > > > > The mechanism for selecting which security modules are > > active has been changed to allow non-conflicting "major" > > security modules to be used together. At this time the > > TOMOYO module can safely be used with any of the others. > > The two new modules would be non-conflicting as well. > > > > Signed-off-by: Casey Schaufler > > --- > > Documentation/admin-guide/LSM/index.rst | 14 +++-- > > include/linux/lsm_hooks.h | 2 +- > > security/Kconfig | 81 +++++++++++++++++++++++++ > > security/apparmor/include/cred.h | 8 +++ > > security/apparmor/include/file.h | 9 ++- > > security/apparmor/include/lib.h | 4 ++ > > security/apparmor/lsm.c | 8 ++- > > security/security.c | 30 ++++++++- > > security/selinux/hooks.c | 3 +- > > security/selinux/include/objsec.h | 18 +++++- > > security/smack/smack.h | 19 +++++- > > security/smack/smack_lsm.c | 17 +++--- > > security/tomoyo/common.h | 12 +++- > > security/tomoyo/tomoyo.c | 3 +- > > 14 files changed, 200 insertions(+), 28 deletions(-) ... > > diff --git a/security/Kconfig b/security/Kconfig > > index 22f7664c4977..ed48025ae9e0 100644 > > --- a/security/Kconfig > > +++ b/security/Kconfig > > @@ -36,6 +36,28 @@ config SECURITY_WRITABLE_HOOKS > > bool > > default n > > > > +config SECURITY_STACKING > > + bool "Security module stacking" > > + depends on SECURITY > > + help > > + Allows multiple major security modules to be stacked. > > + Modules are invoked in the order registered with a > > + "bail on fail" policy, in which the infrastructure > > + will stop processing once a denial is detected. Not > > + all modules can be stacked. SELinux, Smack and AppArmor are > > + known to be incompatible. User space components may > > + have trouble identifying the security module providing > > + data in some cases. > > + > > + If you select this option you will have to select which > > + of the stackable modules you wish to be active. The > > + "Default security module" will be ignored. The boot line > > + "security=" option can be used to specify that one of > > + the modules identifed for stacking should be used instead > > + of the entire stack. > > + > > + If you are unsure how to answer this question, answer N. > > I don't see a good reason to make this a config. Why shouldn't this > always be enabled? I do. From a user perspective it is sometimes difficult to determine the reason behind a failed operation; its is a DAC based denial, the LSM, or some other failure? Stacking additional LSMs has the potential to make this worse. The boot time configuration adds to the complexity. I think we should leave this decision to the individual distros so that they can make their own decision on LSM stacking based on the savviness of their user base and the quality of their support infrastructure. -- paul moore www.paul-moore.com