From: Paul Moore <paul@paul-moore.com> To: Golden_Miller83@protonmail.ch Cc: keescook@chromium.org, casey@schaufler-ca.com, linux-security-module@vger.kernel.org, James Morris <jmorris@namei.org>, linux-kernel@vger.kernel.org, selinux@tycho.nsa.gov, john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp, Stephen Smalley <sds@tycho.nsa.gov>, linux-fsdevel@vger.kernel.org, casey.schaufler@intel.com Subject: Re: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock Date: Thu, 13 Sep 2018 17:50:48 -0400 [thread overview] Message-ID: <CAHC9VhR0qfTn3qwVGpBV=LcM8O1jz-dmqxTW0OqJ-xfO+1k6ew@mail.gmail.com> (raw) In-Reply-To: <tb3zfQ7fac9Oth8YArOo84SbMfqV1s0DjOmVy7op90J_o1XOaEjflZloOpj9PIiUQRhKJxhauXzJD3irkSSjOXK94qYlfQ1frIQiH1OTWPQ=@protonmail.ch> On Thu, Sep 13, 2018 at 4:58 PM Jordan Glover <Golden_Miller83@protonmail.ch> wrote: > > On Thursday, September 13, 2018 9:12 PM, Paul Moore <paul@paul-moore.com> wrote: > > > On Thu, Sep 13, 2018 at 11:19 AM Kees Cook keescook@chromium.org wrote: > > > > > On Thu, Sep 13, 2018 at 6:16 AM, Paul Moore paul@paul-moore.com wrote: > > > > > > > On Thu, Sep 13, 2018 at 12:19 AM Kees Cook keescook@chromium.org wrote: ... > > > > > 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. > > > > > > Let me try to convince you otherwise. :) The reason I think there's no > > > need for this is because the only functional change here is how > > > TOMOYO gets stacked. And in my proposal, we can convert TOMOYO to be > > > enabled/disabled like LoadPin. Given the configs I showed, stacking > > > TOMOYO with the other major LSMs becomes a config (and/or boottime) > > > option. > > > The changes for TOMOYO are still needed even with SECURITY_STACKING, > > > and I argue that the other major LSMs remain the same. It's only > > > infrastructure that has changed. So, I think having SECURITY_STACKING > > > actually makes things more complex internally (all the ifdefs, weird > > > enable logic) and for distros ("what's this stacking option", etc?) > > > > None of the above deals with the user experience or support burden a > > distro would have by forcing stacking on. If we make it an option the > > distros can choose for themselves; picking a kernel build config is > > not something new to distros, and I think Casey's text adequately > > explains CONFIG_SECURITY_STACKING in terms that would be sufficient. > > CONFIG_SECURITY_STACKING doesn't make any user visible changes on > itself as it doesn't automatically enable any new LSM. The LSM > specific configs are place where users/distros make decisions. If > there is only one LSM enabled to run then there's nothing to stack. > If someone choose to run two or more LSM in config/boot cmdline > then we can assume having it stacked is what they wanted. As Kees > pointed there is already CONFIG_SECURITY_DEFAULT_XXX. In both cases > CONFIG_SECURITY_STACKING is redundant and only adds burden instead > of removing it. See my last response to Kees. > > I currently have a neutral stance on stacking, making it mandatory > > pushes me more towards a "no". > > This implies that your real concern is something else than > CONFIG_SECURITY_STACKING which only allows you to ignore the whole > thing. Please reveal it. There are a lot of people waiting for LSM > stacking which is several years late and it would be great to > resolve potential issues earlier rather later. What? I resent the implication that I'm hiding anything; there are a lot of fair criticisms you could level at me, but I take offense at the idea that I'm not being honest here. I've been speaking with Casey, John, and others about stacking for years, both on-list and in-person at conferences, and my neutral-opinion-just-make-it-work-for-everything-and-make-it-optional stance has been pretty consistent and isn't new. Also, let's be really clear here: I'm only asking that stacking be made a build time option (as it is in Casey's patchset). That seems like a pretty modest ask for something so significant and "several years late" as you put it. -- paul moore www.paul-moore.com
WARNING: multiple messages have this Message-ID (diff)
From: paul@paul-moore.com (Paul Moore) To: linux-security-module@vger.kernel.org Subject: [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock Date: Thu, 13 Sep 2018 17:50:48 -0400 [thread overview] Message-ID: <CAHC9VhR0qfTn3qwVGpBV=LcM8O1jz-dmqxTW0OqJ-xfO+1k6ew@mail.gmail.com> (raw) In-Reply-To: <tb3zfQ7fac9Oth8YArOo84SbMfqV1s0DjOmVy7op90J_o1XOaEjflZloOpj9PIiUQRhKJxhauXzJD3irkSSjOXK94qYlfQ1frIQiH1OTWPQ=@protonmail.ch> On Thu, Sep 13, 2018 at 4:58 PM Jordan Glover <Golden_Miller83@protonmail.ch> wrote: > > On Thursday, September 13, 2018 9:12 PM, Paul Moore <paul@paul-moore.com> wrote: > > > On Thu, Sep 13, 2018 at 11:19 AM Kees Cook keescook at chromium.org wrote: > > > > > On Thu, Sep 13, 2018 at 6:16 AM, Paul Moore paul at paul-moore.com wrote: > > > > > > > On Thu, Sep 13, 2018 at 12:19 AM Kees Cook keescook at chromium.org wrote: ... > > > > > 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. > > > > > > Let me try to convince you otherwise. :) The reason I think there's no > > > need for this is because the only functional change here is how > > > TOMOYO gets stacked. And in my proposal, we can convert TOMOYO to be > > > enabled/disabled like LoadPin. Given the configs I showed, stacking > > > TOMOYO with the other major LSMs becomes a config (and/or boottime) > > > option. > > > The changes for TOMOYO are still needed even with SECURITY_STACKING, > > > and I argue that the other major LSMs remain the same. It's only > > > infrastructure that has changed. So, I think having SECURITY_STACKING > > > actually makes things more complex internally (all the ifdefs, weird > > > enable logic) and for distros ("what's this stacking option", etc?) > > > > None of the above deals with the user experience or support burden a > > distro would have by forcing stacking on. If we make it an option the > > distros can choose for themselves; picking a kernel build config is > > not something new to distros, and I think Casey's text adequately > > explains CONFIG_SECURITY_STACKING in terms that would be sufficient. > > CONFIG_SECURITY_STACKING doesn't make any user visible changes on > itself as it doesn't automatically enable any new LSM. The LSM > specific configs are place where users/distros make decisions. If > there is only one LSM enabled to run then there's nothing to stack. > If someone choose to run two or more LSM in config/boot cmdline > then we can assume having it stacked is what they wanted. As Kees > pointed there is already CONFIG_SECURITY_DEFAULT_XXX. In both cases > CONFIG_SECURITY_STACKING is redundant and only adds burden instead > of removing it. See my last response to Kees. > > I currently have a neutral stance on stacking, making it mandatory > > pushes me more towards a "no". > > This implies that your real concern is something else than > CONFIG_SECURITY_STACKING which only allows you to ignore the whole > thing. Please reveal it. There are a lot of people waiting for LSM > stacking which is several years late and it would be great to > resolve potential issues earlier rather later. What? I resent the implication that I'm hiding anything; there are a lot of fair criticisms you could level at me, but I take offense at the idea that I'm not being honest here. I've been speaking with Casey, John, and others about stacking for years, both on-list and in-person at conferences, and my neutral-opinion-just-make-it-work-for-everything-and-make-it-optional stance has been pretty consistent and isn't new. Also, let's be really clear here: I'm only asking that stacking be made a build time option (as it is in Casey's patchset). That seems like a pretty modest ask for something so significant and "several years late" as you put it. -- paul moore www.paul-moore.com
next prev parent reply other threads:[~2018-09-13 21:51 UTC|newest] Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-11 16:26 [PATCH v2 00/10] LSM: Module stacking in support of S.A.R.A and Landlock Casey Schaufler 2018-09-11 16:26 ` Casey Schaufler 2018-09-11 16:41 ` [PATCH 01/10] procfs: add smack subdir to attrs Casey Schaufler 2018-09-11 16:41 ` Casey Schaufler 2018-09-11 23:45 ` Ahmed S. Darwish 2018-09-11 23:45 ` Ahmed S. Darwish 2018-09-12 0:01 ` Casey Schaufler 2018-09-12 0:01 ` Casey Schaufler 2018-09-12 22:57 ` Kees Cook 2018-09-12 22:57 ` Kees Cook 2018-09-11 16:41 ` [PATCH 02/10] Smack: Abstract use of cred security blob Casey Schaufler 2018-09-11 16:41 ` Casey Schaufler 2018-09-12 23:04 ` Kees Cook 2018-09-12 23:04 ` Kees Cook 2018-09-11 16:41 ` [PATCH 03/10] SELinux: " Casey Schaufler 2018-09-11 16:41 ` Casey Schaufler 2018-09-12 23:10 ` Kees Cook 2018-09-12 23:10 ` Kees Cook 2018-09-11 16:41 ` [PATCH 04/10] LSM: Infrastructure management of the " Casey Schaufler 2018-09-11 16:41 ` Casey Schaufler 2018-09-12 23:53 ` Kees Cook 2018-09-12 23:53 ` Kees Cook 2018-09-13 19:01 ` Casey Schaufler 2018-09-13 19:01 ` Casey Schaufler 2018-09-13 21:12 ` Kees Cook 2018-09-13 21:12 ` Kees Cook 2018-09-11 16:41 ` [PATCH 05/10] SELinux: Abstract use of file " Casey Schaufler 2018-09-11 16:41 ` Casey Schaufler 2018-09-12 23:54 ` Kees Cook 2018-09-12 23:54 ` Kees Cook 2018-09-11 16:42 ` [PATCH 06/10] LSM: Infrastructure management of the " Casey Schaufler 2018-09-11 16:42 ` Casey Schaufler 2018-09-13 0:00 ` Kees Cook 2018-09-13 0:00 ` Kees Cook 2018-09-11 16:42 ` [PATCH 07/10] SELinux: Abstract use of inode " Casey Schaufler 2018-09-11 16:42 ` Casey Schaufler 2018-09-13 0:23 ` Kees Cook 2018-09-13 0:23 ` Kees Cook 2018-09-11 16:42 ` [PATCH 08/10] Smack: " Casey Schaufler 2018-09-11 16:42 ` Casey Schaufler 2018-09-13 0:24 ` Kees Cook 2018-09-13 0:24 ` Kees Cook 2018-09-11 16:42 ` [PATCH 09/10] LSM: Infrastructure management of the inode security Casey Schaufler 2018-09-11 16:42 ` Casey Schaufler 2018-09-13 0:30 ` Kees Cook 2018-09-13 0:30 ` Kees Cook 2018-09-11 16:42 ` [PATCH 10/10] LSM: Blob sharing support for S.A.R.A and LandLock Casey Schaufler 2018-09-11 16:42 ` Casey Schaufler 2018-09-13 4:19 ` Kees Cook 2018-09-13 4:19 ` Kees Cook 2018-09-13 13:16 ` Paul Moore 2018-09-13 13:16 ` Paul Moore 2018-09-13 15:19 ` Kees Cook 2018-09-13 15:19 ` Kees Cook 2018-09-13 19:12 ` Paul Moore 2018-09-13 19:12 ` Paul Moore 2018-09-13 20:58 ` Jordan Glover 2018-09-13 20:58 ` Jordan Glover 2018-09-13 20:58 ` Jordan Glover 2018-09-13 21:50 ` Paul Moore [this message] 2018-09-13 21:50 ` Paul Moore 2018-09-13 22:04 ` Jordan Glover 2018-09-13 22:04 ` Jordan Glover 2018-09-13 22:04 ` Jordan Glover 2018-09-13 23:01 ` Casey Schaufler 2018-09-13 23:01 ` Casey Schaufler 2018-09-13 21:01 ` Kees Cook 2018-09-13 21:01 ` Kees Cook 2018-09-13 21:38 ` Paul Moore 2018-09-13 21:38 ` Paul Moore 2018-09-13 21:51 ` Kees Cook 2018-09-13 21:51 ` Kees Cook 2018-09-13 23:06 ` Kees Cook 2018-09-13 23:06 ` Kees Cook 2018-09-13 23:32 ` John Johansen 2018-09-13 23:32 ` John Johansen 2018-09-13 23:51 ` Kees Cook 2018-09-13 23:51 ` Kees Cook 2018-09-14 0:03 ` Casey Schaufler 2018-09-14 0:03 ` Casey Schaufler 2018-09-14 0:06 ` Kees Cook 2018-09-14 0:06 ` Kees Cook 2018-09-13 23:51 ` Casey Schaufler 2018-09-13 23:51 ` Casey Schaufler 2018-09-13 23:57 ` Kees Cook 2018-09-13 23:57 ` Kees Cook 2018-09-14 0:08 ` Casey Schaufler 2018-09-14 0:08 ` Casey Schaufler 2018-09-14 0:19 ` Kees Cook 2018-09-14 0:19 ` Kees Cook 2018-09-14 15:57 ` Casey Schaufler 2018-09-14 15:57 ` Casey Schaufler 2018-09-14 20:05 ` Kees Cook 2018-09-14 20:05 ` Kees Cook 2018-09-14 20:47 ` Casey Schaufler 2018-09-14 20:47 ` Casey Schaufler 2018-09-14 18:18 ` James Morris 2018-09-14 18:18 ` James Morris 2018-09-14 18:23 ` John Johansen 2018-09-14 18:23 ` John Johansen 2018-09-14 0:03 ` Kees Cook 2018-09-14 0:03 ` Kees Cook 2018-09-14 2:42 ` Paul Moore 2018-09-14 2:42 ` Paul Moore 2018-09-11 20:43 ` [PATCH v2 00/10] LSM: Module stacking in support of S.A.R.A and Landlock James Morris 2018-09-11 20:43 ` James Morris 2018-09-12 21:29 ` James Morris 2018-09-12 21:29 ` James Morris 2018-09-16 16:54 ` Salvatore Mesoraca 2018-09-16 16:54 ` Salvatore Mesoraca 2018-09-16 17:25 ` Casey Schaufler 2018-09-16 17:25 ` Casey Schaufler 2018-09-16 17:45 ` Salvatore Mesoraca 2018-09-16 17:45 ` Salvatore Mesoraca 2018-09-18 7:44 ` Mickaël Salaün 2018-09-18 15:23 ` Casey Schaufler 2018-09-18 15:23 ` Casey Schaufler
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAHC9VhR0qfTn3qwVGpBV=LcM8O1jz-dmqxTW0OqJ-xfO+1k6ew@mail.gmail.com' \ --to=paul@paul-moore.com \ --cc=Golden_Miller83@protonmail.ch \ --cc=casey.schaufler@intel.com \ --cc=casey@schaufler-ca.com \ --cc=jmorris@namei.org \ --cc=john.johansen@canonical.com \ --cc=keescook@chromium.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=penguin-kernel@i-love.sakura.ne.jp \ --cc=sds@tycho.nsa.gov \ --cc=selinux@tycho.nsa.gov \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.