From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f194.google.com ([209.85.208.194]:37103 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727092AbeINHz0 (ORCPT ); Fri, 14 Sep 2018 03:55:26 -0400 Received: by mail-lj1-f194.google.com with SMTP id v9-v6so6271395ljk.4 for ; Thu, 13 Sep 2018 19:43:12 -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 22:42:59 -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 5:52 PM Kees Cook wrote: > On Thu, Sep 13, 2018 at 2:38 PM, Paul Moore wrote: > > The infrastructure bits aren't really my concern; in fact I *like* > > that the infrastructure is always exercised, it makes > > testing/debugging easier. I also like the ability to limit the > > user/admin to one LSM at boot time to make support easier; my goal is > > to allow a distro to build support for multiple LSMs without also > > requiring that distro to support *stacked* LSMs > > I see your point, but as soon as SARA and Landlock appear, they'll have: > > depends on SECURITY_STACKING > > and then all distros will enable it and there will be no sensible > runtime way to manage it. If, instead, we make it entirely runtime > now, then a CONFIG can control the default state and we can provide > guidance to how SARA and Landlock should expose their "enable"ness. I question why SARA and LandLock require stacking. While some LSMs may benefit from stacking, e.g. Yama, traditionally each LSM has been able to stand on its own. I think this is a quality that should be preserved. > > (see my earlier > > comments about the difficulty in determining the source of a failed > > operation). > > Agreed. I would hope that audit could help for that case. *stare at blue sky* *also staring at blue sky* Audit can help, but it is independent of the LSMs and not a hard requirement for all, and even when it is enabled the config might not be suitable to provide enough information to be helpful in this case. -- paul moore www.paul-moore.com