From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH security-next v5 00/30] LSM: Explict ordering Date: Tue, 23 Oct 2018 11:50:21 -0700 Message-ID: References: <20181011001846.30964-1-keescook@chromium.org> <32stV62RmME8Dj5jKB8Z03zPe_Et72kMo71D8SpgSOHUo6SaROc8DomMWdk5jDGpyqVd8T63NIIK2NdDw95clpF8Uj47Wca2FBFItXDRh7E=@protonmail.ch> <38dde301-d77e-35fd-88d4-5cdc5b570ee8@canonical.com> <_CkJnKYmEZ4ZF0JtsSYuahAd9sgnX9OtcstjXaeqb8wn5uxfimc6S4jomly7If9VqnOXqXwaiCbJ9ttS6NiqE7n6cQUlwLvfO53paLmacvU=@protonmail.ch> <8251564f-ba7a-1777-a606-dec472b32f35@canonical.com> <96e92224-aedf-5026-d6dd-b29121b4dc0d@schaufler-ca.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: <96e92224-aedf-5026-d6dd-b29121b4dc0d@schaufler-ca.com> Sender: linux-kernel-owner@vger.kernel.org To: Casey Schaufler Cc: John Johansen , Jordan Glover , James Morris , Stephen Smalley , Paul Moore , Tetsuo Handa , Mimi Zohar , Randy Dunlap , LSM , "open list:DOCUMENTATION" , linux-arch , LKML List-Id: linux-arch.vger.kernel.org On Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler wrote: > On 10/12/2018 12:01 PM, Kees Cook wrote: >> On Friday, October 12, 2018 3:19 AM, John Johansen >> wrote: >>> It isn't perfect but it manages consistency across distros as best as >>> can be achieved atm. >> Yeah, this is why I'm okay with the current series: it provides as >> consistent a view as possible, but leaves room for future improvements >> (like adding "+" or "!" or "all" or whatever). >> >> I'm curious to see what SELinux folks think of v5, though. I *think* I >> addressed all the concerns there, even Paul's "I want my distro >> default to not have extreme stacking" case too. >> >> -Kees > > Looks like I should go on vacation more often. :) > > I am generally opposed to fancy specification languages. > I support the explicit lsm= list specification because you > don't have to know any context to create a boot line that > will work, and be as close to what you've specified as possible > for the kernel configuration. One need look no further than > the mechanisms for setting POSIX ACLs for an example of > how to ensure a feature isn't used. > > Had we the foresight to make security= take a list of > modules when Yama was added we might have avoided some of > this brouhaha, but there was no reason to expect that stacking > was ever going to happen back then. This sounds like an "Ack" for you? :) I'll harass everyone in person in a couple days. Did you poke around at my combined series? https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-f194.google.com ([209.85.219.194]:46555 "EHLO mail-yb1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727829AbeJXDPC (ORCPT ); Tue, 23 Oct 2018 23:15:02 -0400 Received: by mail-yb1-f194.google.com with SMTP id o8-v6so1002486ybk.13 for ; Tue, 23 Oct 2018 11:50:25 -0700 (PDT) Received: from mail-yw1-f49.google.com (mail-yw1-f49.google.com. [209.85.161.49]) by smtp.gmail.com with ESMTPSA id e206-v6sm526862ywc.8.2018.10.23.11.50.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Oct 2018 11:50:23 -0700 (PDT) Received: by mail-yw1-f49.google.com with SMTP id j75-v6so986474ywj.10 for ; Tue, 23 Oct 2018 11:50:22 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <96e92224-aedf-5026-d6dd-b29121b4dc0d@schaufler-ca.com> References: <20181011001846.30964-1-keescook@chromium.org> <32stV62RmME8Dj5jKB8Z03zPe_Et72kMo71D8SpgSOHUo6SaROc8DomMWdk5jDGpyqVd8T63NIIK2NdDw95clpF8Uj47Wca2FBFItXDRh7E=@protonmail.ch> <38dde301-d77e-35fd-88d4-5cdc5b570ee8@canonical.com> <_CkJnKYmEZ4ZF0JtsSYuahAd9sgnX9OtcstjXaeqb8wn5uxfimc6S4jomly7If9VqnOXqXwaiCbJ9ttS6NiqE7n6cQUlwLvfO53paLmacvU=@protonmail.ch> <8251564f-ba7a-1777-a606-dec472b32f35@canonical.com> <96e92224-aedf-5026-d6dd-b29121b4dc0d@schaufler-ca.com> From: Kees Cook Date: Tue, 23 Oct 2018 11:50:21 -0700 Message-ID: Subject: Re: [PATCH security-next v5 00/30] LSM: Explict ordering Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Casey Schaufler Cc: John Johansen , Jordan Glover , James Morris , Stephen Smalley , Paul Moore , Tetsuo Handa , Mimi Zohar , Randy Dunlap , LSM , "open list:DOCUMENTATION" , linux-arch , LKML Message-ID: <20181023185021.sW80IVNrKmmdLlXEdBn6ubVVN7jC63AP1ZkbRUpY4kg@z> On Tue, Oct 23, 2018 at 9:48 AM, Casey Schaufler wrote: > On 10/12/2018 12:01 PM, Kees Cook wrote: >> On Friday, October 12, 2018 3:19 AM, John Johansen >> wrote: >>> It isn't perfect but it manages consistency across distros as best as >>> can be achieved atm. >> Yeah, this is why I'm okay with the current series: it provides as >> consistent a view as possible, but leaves room for future improvements >> (like adding "+" or "!" or "all" or whatever). >> >> I'm curious to see what SELinux folks think of v5, though. I *think* I >> addressed all the concerns there, even Paul's "I want my distro >> default to not have extreme stacking" case too. >> >> -Kees > > Looks like I should go on vacation more often. :) > > I am generally opposed to fancy specification languages. > I support the explicit lsm= list specification because you > don't have to know any context to create a boot line that > will work, and be as close to what you've specified as possible > for the kernel configuration. One need look no further than > the mechanisms for setting POSIX ACLs for an example of > how to ensure a feature isn't used. > > Had we the foresight to make security= take a list of > modules when Yama was added we might have avoided some of > this brouhaha, but there was no reason to expect that stacking > was ever going to happen back then. This sounds like an "Ack" for you? :) I'll harass everyone in person in a couple days. Did you poke around at my combined series? https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/log/?h=lsm/ordering-v6-blob-sharing -Kees -- Kees Cook Pixel Security