From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f67.google.com ([209.85.161.67]:40770 "EHLO mail-yw1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728161AbeINDDW (ORCPT ); Thu, 13 Sep 2018 23:03:22 -0400 Received: by mail-yw1-f67.google.com with SMTP id z143-v6so1821018ywa.7 for ; Thu, 13 Sep 2018 14:52:01 -0700 (PDT) Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com. [209.85.219.176]) by smtp.gmail.com with ESMTPSA id i123-v6sm6620588ywe.14.2018.09.13.14.51.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Sep 2018 14:51:59 -0700 (PDT) Received: by mail-yb1-f176.google.com with SMTP id j8-v6so3937666ybg.9 for ; Thu, 13 Sep 2018 14:51:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <99cb1ae7-8881-eb9a-a8cb-a787abe454e1@schaufler-ca.com> From: Kees Cook Date: Thu, 13 Sep 2018 14:51:57 -0700 Message-ID: Subject: Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock To: Paul Moore Cc: Casey Schaufler , linux-security-module , James Morris , LKML , SE Linux , John Johansen , Tetsuo Handa , Stephen Smalley , "linux-fsdevel@vger.kernel.org" , Alexey Dobriyan , "Schaufler, Casey" Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. At the very least, to avoid stacking now (i.e. TOMOYO being enabled with another major LSM), we just do nothing. The existing code already makes the existing major LSMs exclusive. Adding a stackable LSM would need to just have its own "enable" flag (i.e. ignore security_module_enable()), and then either check a runtime "is stacking allowed?" flag or have new "depends on SECURITY_STACKING". (I think the CONFIG will force distros into enabling it without any runtime opt-out.) > (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* -Kees -- Kees Cook Pixel Security