From: Casey Schaufler <casey@schaufler-ca.com> To: Kees Cook <keescook@chromium.org>, John Johansen <john.johansen@canonical.com> Cc: James Morris <jmorris@namei.org>, Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>, Paul Moore <paul@paul-moore.com>, Stephen Smalley <sds@tycho.nsa.gov>, "Schaufler, Casey" <casey.schaufler@intel.com>, LSM <linux-security-module@vger.kernel.org>, LKLM <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 16/18] LSM: Allow arbitrary LSM ordering Date: Mon, 17 Sep 2018 17:24:37 -0700 [thread overview] Message-ID: <ee3b287d-95a4-db16-e3c6-fc6f6172a5ae@schaufler-ca.com> (raw) In-Reply-To: <CAGXu5jKhZTcz_+uQpNRh6Mg34pP2+aNSo9cV=c8pC0r=oJBJog@mail.gmail.com> On 9/17/2018 5:00 PM, Kees Cook wrote: > On Mon, Sep 17, 2018 at 3:36 PM, John Johansen > <john.johansen@canonical.com> wrote: >> On 09/17/2018 02:57 PM, Casey Schaufler wrote: >>> Modules not listed may go anywhere there is a "*" in the order. >>> An lsm.order= without a "*" is an error, and ignored. >>> If a module is specified in lsm.order but not built in it is ignored. >>> If a module is specified but disabled it is ignored. >>> The capability module goes first regardless. >> I don't mind using lsm.order if we must but really do not like the '*' >> idea. It makes this way more complicated than it needs to be > Having the "*" means that _not_ having it in "lsm.order=" is an > implicit form of LSM disabling. That's not what I said. What I said was that without a "*" the ordering goes back to what was specified at build time. lsm.order does nothing with enablement or disablement. If you say "lsm.order=smack,sara,*" and sara is not compiled in you get smack followed by everything else. > And I think we've gotten to the point > where we agree on the enable/disable logic, so I don't want to mess > that up again. > > For enable/disable, I think we're agreed on: > > lsm.enable=$lsm > lsm.disable=$lsm Works for me. > lsm.disable takes precedent for disabling. (e.g. "lsm.disable=apparmor > apparmor.enable=1" will leave apparmor disabled) > lsm.enable will allow per-LSM enable/disable to operate. (e.g. > "lsm.enable=apparmor apparmor.enable=0" will leave apparmor disabled) > > lsm.enable/disable ordering will be "last match": "lsm.disable=smack > lsm.enable=smack" will leave smack enabled. So far do good. > The legacy per-LSM > enable/disable ordering is the same, but ordering between > lsm.enable/disable and the per-LSM options is NOT ordered. i.e. the > precedent mentioned in the prior paragraph. That is, capability,yama,loadpin,<major> > To support "security=", we'll still have some kind of legacy > LSM_FLAG_MAJOR to perform implicit disabling of the non-operational > other "major" LSMs. This means "security=$foo" will be a short-hand > for "lsm.disable=all-LSM_FLAG_MAJOR-who-are-not-$foo". This will > exactly match current behavior (i.e. "security=smack" and if smack > fails initialization, we do not then fall back to another major). Right. > I think we have to support runtime ordering for the reasons John > specifies. Additionally, I have the sense that anything we can > configure in Kconfig ultimately ends up being expressed at runtime > too, so better to just make sure the design includes it now. Right. > What we have now: > > "first" then "order-doesn't-matter-minors" then "exclusive-major" > > - we can't change first. > - exclusivity-ordering only matters in the face of enable/disable > which we have solved now (?) I'm not sure where you get the conclusion we've solved this. Today I can't say "lsm.enable=smack lsm.enable=apparmor", and there's no mechanism to prevent that. > so, ordering can be totally arbitrary after "first" (but before some > future "last"). We must not allow a token for "everything else" since > that overlaps with enable/disable, so "everything else" stay implicit > (I would argue a trailing implicit ordering). There's an assumption you're making that I'm not getting. Where does this overlap between ordering and enable/disable come from? > The one complication I see with ordering, then, is that if we change > the exclusivity over time, we change what may be present on the > system. For example, right now tomoyo is exclusive. Once we have > blob-sharing, it doesn't need to be. > > so: lsm.order=tomoyo after this series means > "capability,tomoyo,yama,loadpin,integrity", but when tomoyo becomes > non-exclusive, suddenly we get > "capability,tomoyo,yama,loadpin,{selinux,smack,apparmor},integrity". > (i.e. if selinux is disabled then move on to trying smack, then > apparmor, etc.) We're missing a description of what happens at build time. It's hard to see what you expect to happen if I want to build in all the major modules and don't plan to use the boot command line options. > I would argue that this is a design feature (LSMs aren't left behind), > and order of enabled exclusive LSMs "wins" the choice for the > exclusivity (instead of operating "by name" the way "security=" > works). I think I see more, but I'm guessing. At build time it looks like you're dropping the specification on the "major" module. We can't do that because I want to build kernels that run Smack by default but include SELinux for when I'm feeling less evil than normal.
WARNING: multiple messages have this Message-ID (diff)
From: casey@schaufler-ca.com (Casey Schaufler) To: linux-security-module@vger.kernel.org Subject: [PATCH 16/18] LSM: Allow arbitrary LSM ordering Date: Mon, 17 Sep 2018 17:24:37 -0700 [thread overview] Message-ID: <ee3b287d-95a4-db16-e3c6-fc6f6172a5ae@schaufler-ca.com> (raw) In-Reply-To: <CAGXu5jKhZTcz_+uQpNRh6Mg34pP2+aNSo9cV=c8pC0r=oJBJog@mail.gmail.com> On 9/17/2018 5:00 PM, Kees Cook wrote: > On Mon, Sep 17, 2018 at 3:36 PM, John Johansen > <john.johansen@canonical.com> wrote: >> On 09/17/2018 02:57 PM, Casey Schaufler wrote: >>> Modules not listed may go anywhere there is a "*" in the order. >>> An lsm.order= without a "*" is an error, and ignored. >>> If a module is specified in lsm.order but not built in it is ignored. >>> If a module is specified but disabled it is ignored. >>> The capability module goes first regardless. >> I don't mind using lsm.order if we must but really do not like the '*' >> idea. It makes this way more complicated than it needs to be > Having the "*" means that _not_ having it in "lsm.order=" is an > implicit form of LSM disabling. That's not what I said. What I said was that without a "*" the ordering goes back to what was specified at build time. lsm.order does nothing with enablement or disablement. If you say "lsm.order=smack,sara,*" and sara is not compiled in you get smack followed by everything else. > And I think we've gotten to the point > where we agree on the enable/disable logic, so I don't want to mess > that up again. > > For enable/disable, I think we're agreed on: > > lsm.enable=$lsm > lsm.disable=$lsm Works for me. > lsm.disable takes precedent for disabling. (e.g. "lsm.disable=apparmor > apparmor.enable=1" will leave apparmor disabled) > lsm.enable will allow per-LSM enable/disable to operate. (e.g. > "lsm.enable=apparmor apparmor.enable=0" will leave apparmor disabled) > > lsm.enable/disable ordering will be "last match": "lsm.disable=smack > lsm.enable=smack" will leave smack enabled. So far do good. > The legacy per-LSM > enable/disable ordering is the same, but ordering between > lsm.enable/disable and the per-LSM options is NOT ordered. i.e. the > precedent mentioned in the prior paragraph. That is, capability,yama,loadpin,<major> > To support "security=", we'll still have some kind of legacy > LSM_FLAG_MAJOR to perform implicit disabling of the non-operational > other "major" LSMs. This means "security=$foo" will be a short-hand > for "lsm.disable=all-LSM_FLAG_MAJOR-who-are-not-$foo". This will > exactly match current behavior (i.e. "security=smack" and if smack > fails initialization, we do not then fall back to another major). Right. > I think we have to support runtime ordering for the reasons John > specifies. Additionally, I have the sense that anything we can > configure in Kconfig ultimately ends up being expressed at runtime > too, so better to just make sure the design includes it now. Right. > What we have now: > > "first" then "order-doesn't-matter-minors" then "exclusive-major" > > - we can't change first. > - exclusivity-ordering only matters in the face of enable/disable > which we have solved now (?) I'm not sure where you get the conclusion we've solved this. Today I can't say "lsm.enable=smack lsm.enable=apparmor", and there's no mechanism to prevent that. > so, ordering can be totally arbitrary after "first" (but before some > future "last"). We must not allow a token for "everything else" since > that overlaps with enable/disable, so "everything else" stay implicit > (I would argue a trailing implicit ordering). There's an assumption you're making that I'm not getting. Where does this overlap between ordering and enable/disable come from? > The one complication I see with ordering, then, is that if we change > the exclusivity over time, we change what may be present on the > system. For example, right now tomoyo is exclusive. Once we have > blob-sharing, it doesn't need to be. > > so: lsm.order=tomoyo after this series means > "capability,tomoyo,yama,loadpin,integrity", but when tomoyo becomes > non-exclusive, suddenly we get > "capability,tomoyo,yama,loadpin,{selinux,smack,apparmor},integrity". > (i.e. if selinux is disabled then move on to trying smack, then > apparmor, etc.) We're missing a description of what happens at build time. It's hard to see what you expect to happen if I want to build in all the major modules and don't plan to use the boot command line options. > I would argue that this is a design feature (LSMs aren't left behind), > and order of enabled exclusive LSMs "wins" the choice for the > exclusivity (instead of operating "by name" the way "security=" > works). I think I see more, but I'm guessing. At build time it looks like you're dropping the specification on the "major" module. We can't do that because I want to build kernels that run Smack by default but include SELinux for when I'm feeling less evil than normal.
next prev parent reply other threads:[~2018-09-18 0:24 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-09-16 0:30 [PATCH 00/18] LSM: Prepare for explict LSM ordering Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 01/18] vmlinux.lds.h: Avoid copy/paste of security_init section Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 02/18] LSM: Rename .security_initcall section to .lsm_info Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 03/18] LSM: Remove initcall tracing Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 04/18] LSM: Convert from initcall to struct lsm_info Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 05/18] vmlinux.lds.h: Move LSM_TABLE into INIT_DATA Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 06/18] LSM: Convert security_initcall() into DEFINE_LSM() Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 07/18] LSM: Add minor LSM initialization loop Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 1:27 ` Jann Horn 2018-09-16 1:27 ` Jann Horn 2018-09-16 1:49 ` Kees Cook 2018-09-16 1:49 ` Kees Cook 2018-09-16 0:30 ` [PATCH 08/18] integrity: Initialize as LSM_TYPE_MINOR Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 09/18] LSM: Record LSM name in struct lsm_info Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 10/18] LSM: Plumb visibility into optional "enabled" state Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 11/18] LSM: Lift LSM selection out of individual LSMs Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 1:32 ` Jann Horn 2018-09-16 1:32 ` Jann Horn 2018-09-16 1:47 ` Kees Cook 2018-09-16 1:47 ` Kees Cook 2018-09-16 0:30 ` [PATCH 12/18] LSM: Introduce ordering details in struct lsm_info Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 13/18] LoadPin: Initialize as LSM_TYPE_MINOR Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 14/18] Yama: " Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 15/18] capability: " Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 16/18] LSM: Allow arbitrary LSM ordering Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 18:49 ` Casey Schaufler 2018-09-16 18:49 ` Casey Schaufler 2018-09-16 23:00 ` Kees Cook 2018-09-16 23:00 ` Kees Cook 2018-09-17 0:46 ` Tetsuo Handa 2018-09-17 0:46 ` Tetsuo Handa 2018-09-17 15:06 ` Casey Schaufler 2018-09-17 15:06 ` Casey Schaufler 2018-09-17 16:24 ` Kees Cook 2018-09-17 16:24 ` Kees Cook 2018-09-17 17:13 ` Casey Schaufler 2018-09-17 17:13 ` Casey Schaufler 2018-09-17 18:14 ` Kees Cook 2018-09-17 18:14 ` Kees Cook 2018-09-17 19:23 ` Casey Schaufler 2018-09-17 19:23 ` Casey Schaufler 2018-09-17 19:55 ` John Johansen 2018-09-17 19:55 ` John Johansen 2018-09-17 21:57 ` Casey Schaufler 2018-09-17 21:57 ` Casey Schaufler 2018-09-17 22:36 ` John Johansen 2018-09-17 22:36 ` John Johansen 2018-09-17 23:10 ` Mickaël Salaün 2018-09-17 23:20 ` Kees Cook 2018-09-17 23:20 ` Kees Cook 2018-09-17 23:26 ` John Johansen 2018-09-17 23:26 ` John Johansen 2018-09-17 23:28 ` Kees Cook 2018-09-17 23:28 ` Kees Cook 2018-09-17 23:40 ` Casey Schaufler 2018-09-17 23:40 ` Casey Schaufler 2018-09-17 23:30 ` Casey Schaufler 2018-09-17 23:30 ` Casey Schaufler 2018-09-17 23:47 ` Mickaël Salaün 2018-09-18 0:00 ` Casey Schaufler 2018-09-18 0:00 ` Casey Schaufler 2018-09-17 23:25 ` John Johansen 2018-09-17 23:25 ` John Johansen 2018-09-17 23:25 ` Casey Schaufler 2018-09-17 23:25 ` Casey Schaufler 2018-09-18 0:00 ` Kees Cook 2018-09-18 0:00 ` Kees Cook 2018-09-18 0:24 ` Casey Schaufler [this message] 2018-09-18 0:24 ` Casey Schaufler 2018-09-18 0:45 ` Kees Cook 2018-09-18 0:45 ` Kees Cook 2018-09-18 0:57 ` Casey Schaufler 2018-09-18 0:57 ` Casey Schaufler 2018-09-18 0:59 ` Kees Cook 2018-09-18 0:59 ` Kees Cook 2018-09-18 1:08 ` John Johansen 2018-09-18 1:08 ` John Johansen 2018-09-17 19:35 ` John Johansen 2018-09-17 19:35 ` John Johansen 2018-09-16 0:30 ` [PATCH 17/18] LSM: Provide init debugging Kees Cook 2018-09-16 0:30 ` Kees Cook 2018-09-16 0:30 ` [PATCH 18/18] LSM: Don't ignore initialization failures Kees Cook 2018-09-16 0:30 ` Kees Cook
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=ee3b287d-95a4-db16-e3c6-fc6f6172a5ae@schaufler-ca.com \ --to=casey@schaufler-ca.com \ --cc=casey.schaufler@intel.com \ --cc=jmorris@namei.org \ --cc=john.johansen@canonical.com \ --cc=keescook@chromium.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=paul@paul-moore.com \ --cc=penguin-kernel@i-love.sakura.ne.jp \ --cc=sds@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.