From: Paul Moore <paul@paul-moore.com> To: keescook@chromium.org Cc: 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, adobriyan@gmail.com, 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:38:15 -0400 [thread overview] Message-ID: <CAHC9VhQwT4d3wC37cVrrX-hZq1L3e6=TEAse4m-YH9SiFnkieA@mail.gmail.com> (raw) In-Reply-To: <CAGXu5jKec1JTsoqwKGThcJoamdL618AHu4jfFbqqQiauz1kjyg@mail.gmail.com> On Thu, Sep 13, 2018 at 5:01 PM Kees Cook <keescook@chromium.org> wrote: > On Thu, Sep 13, 2018 at 12:12 PM, Paul Moore <paul@paul-moore.com> wrote: > > 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 > > Just to make sure we're clear here: this series does not provide > "extreme" stacking: SELinux, AppArmor, and SMACK remain boot-exclusive > no matter what the CONFIGs. > > > 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. > > I absolutely want stacking to be configurable, but I want to point out > that there is no operational difference between > CONFIG_SECURITY_STACKING=n and CONFIG_SECURITY_STACKING=y in the code > here: > > - all the new accessor and allocation code is exercised in both cases > > - with stacking enabled: selinux, apparmor, and smack have an offset > of 0 into blobs (and only one can be enabled at a time) > > - with stacking disabled: selinux, apparmor, and smack have an offset > of 0 into blobs (and only one can be enabled at a time) > > The only behavioral difference is TOMOYO: > > 1- with stacking disabled and TOMOYO as the only major LSM, it will > have a 0 offset into blobs (like above) > > 2- with stacking enabled and TOMOYO as the only major LSM, it will > have a 0 offset into blobs (like above) > > 3- with stacking disabled and another major LSM is enabled, TOMOYO > will be disabled (like always) > > 4- with stacking enabled and another major LSM is enabled, TOMOYO will > have a non-0 offset into blobs and will run after selinux or smack or > run before apparmor (based on link ordering defined by the Makefile). Case #3/#4 is what I'm getting at, and I would argue demonstrates an operational difference that is user visible/configurable. Unless something has changed and I missed it, you can currently build all of the LSMs into a single kernel image, and the admin/user can choose one at boot time. CONFIG_SECURITY_STACKING=y enables the admin/user to stack LSMs (albeit with restrictions in the current iteration) and CONFIG_SECURITY_STACKING=n limits the admin/user to a single LSM (what we have now). I understand that as of this moment we are talking only about TOMOYO and AppArmor/Smack/SELinux, but everyone knows that S.A.R.A/SARA and LandLock are going to follow shortly - that's the whole point of this latest spin, isn't it? > > I currently have a neutral stance on stacking, making it mandatory > > pushes me more towards a "no". > > This is why I'm trying to explain myself: the infrastructure proposed > here is always exercised, no matter the CONFIG. From that sense it is > "mandatory" no matter what the config is. There isn't a reality where > you could "turn off stacking", because it's not stacking until you > actually stack something, and that will be disabled by default as I've > proposed it. > > Let me put this another way: if we simply leave off patch 10, we can > take the other 9 patches (modulo feedback), and we only have to decide > how to expose "stacking"; all the infrastructure work for supporting > it is done. > > I'm arguing that "security=" is likely insufficient to describe what > we want, and instead we should focus on individual LSM enablement via > parameters ("tomoyo.enabled=1"). If _ordering_ becomes an issue, we > could either use parameter order, or use "security=" again maybe, but > for now, ordering is already defined by the Makefile (and > security/security.c). 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 (see my earlier comments about the difficulty in determining the source of a failed operation). -- 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:38:15 -0400 [thread overview] Message-ID: <CAHC9VhQwT4d3wC37cVrrX-hZq1L3e6=TEAse4m-YH9SiFnkieA@mail.gmail.com> (raw) In-Reply-To: <CAGXu5jKec1JTsoqwKGThcJoamdL618AHu4jfFbqqQiauz1kjyg@mail.gmail.com> On Thu, Sep 13, 2018 at 5:01 PM Kees Cook <keescook@chromium.org> wrote: > On Thu, Sep 13, 2018 at 12:12 PM, Paul Moore <paul@paul-moore.com> wrote: > > 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 > > Just to make sure we're clear here: this series does not provide > "extreme" stacking: SELinux, AppArmor, and SMACK remain boot-exclusive > no matter what the CONFIGs. > > > 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. > > I absolutely want stacking to be configurable, but I want to point out > that there is no operational difference between > CONFIG_SECURITY_STACKING=n and CONFIG_SECURITY_STACKING=y in the code > here: > > - all the new accessor and allocation code is exercised in both cases > > - with stacking enabled: selinux, apparmor, and smack have an offset > of 0 into blobs (and only one can be enabled at a time) > > - with stacking disabled: selinux, apparmor, and smack have an offset > of 0 into blobs (and only one can be enabled at a time) > > The only behavioral difference is TOMOYO: > > 1- with stacking disabled and TOMOYO as the only major LSM, it will > have a 0 offset into blobs (like above) > > 2- with stacking enabled and TOMOYO as the only major LSM, it will > have a 0 offset into blobs (like above) > > 3- with stacking disabled and another major LSM is enabled, TOMOYO > will be disabled (like always) > > 4- with stacking enabled and another major LSM is enabled, TOMOYO will > have a non-0 offset into blobs and will run after selinux or smack or > run before apparmor (based on link ordering defined by the Makefile). Case #3/#4 is what I'm getting at, and I would argue demonstrates an operational difference that is user visible/configurable. Unless something has changed and I missed it, you can currently build all of the LSMs into a single kernel image, and the admin/user can choose one at boot time. CONFIG_SECURITY_STACKING=y enables the admin/user to stack LSMs (albeit with restrictions in the current iteration) and CONFIG_SECURITY_STACKING=n limits the admin/user to a single LSM (what we have now). I understand that as of this moment we are talking only about TOMOYO and AppArmor/Smack/SELinux, but everyone knows that S.A.R.A/SARA and LandLock are going to follow shortly - that's the whole point of this latest spin, isn't it? > > I currently have a neutral stance on stacking, making it mandatory > > pushes me more towards a "no". > > This is why I'm trying to explain myself: the infrastructure proposed > here is always exercised, no matter the CONFIG. From that sense it is > "mandatory" no matter what the config is. There isn't a reality where > you could "turn off stacking", because it's not stacking until you > actually stack something, and that will be disabled by default as I've > proposed it. > > Let me put this another way: if we simply leave off patch 10, we can > take the other 9 patches (modulo feedback), and we only have to decide > how to expose "stacking"; all the infrastructure work for supporting > it is done. > > I'm arguing that "security=" is likely insufficient to describe what > we want, and instead we should focus on individual LSM enablement via > parameters ("tomoyo.enabled=1"). If _ordering_ becomes an issue, we > could either use parameter order, or use "security=" again maybe, but > for now, ordering is already defined by the Makefile (and > security/security.c). 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 (see my earlier comments about the difficulty in determining the source of a failed operation). -- paul moore www.paul-moore.com
next prev parent reply other threads:[~2018-09-13 21:38 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 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 [this message] 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='CAHC9VhQwT4d3wC37cVrrX-hZq1L3e6=TEAse4m-YH9SiFnkieA@mail.gmail.com' \ --to=paul@paul-moore.com \ --cc=adobriyan@gmail.com \ --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.