From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Morris Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter Date: Fri, 5 Oct 2018 03:49:14 +1000 (AEST) Message-ID: References: <20181002005505.6112-1-keescook@chromium.org> <809f1cfd-077b-ee58-51ba-b22daf46d12b@tycho.nsa.gov> <5955f5ce-b803-4f58-8b07-54c291e33da5@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Kees Cook Cc: John Johansen , Jordan Glover , Stephen Smalley , Paul Moore , Casey Schaufler , Tetsuo Handa , "Schaufler, Casey" , linux-security-module , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML List-Id: linux-arch.vger.kernel.org On Wed, 3 Oct 2018, Kees Cook wrote: > On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote: > > On Wed, 3 Oct 2018, Kees Cook wrote: > > > > - All LSMs which are built are NOT enabled by default > > > > - You specify enablement and order via a Kconfig: > > > > CONFIG_LSM="selinux,yama" > > > > - This can be entirely overridden by a boot param: > > > > lsm="apparmor,landlock" > > This doesn't work with how SELinux and AppArmor do their bootparams, > unfortunately. (And Paul and Stephen have expressed that the > documented selinux on/off must continue to work.) For example, let's > say you've built an Ubuntu kernel with: > > CONFIG_SELINUX=y > ... > CONFIG_LSM="yama,apparmor" > > (i.e. you want SELinux available, but not enabled, so it's left out of > CONFIG_LSM) > > Then someone boots the system with: > > selinux=1 security=selinux > > In what order does selinux get initialized relative to yama? > (apparmor, flagged as a "legacy major", would have been disabled by > the "security=" not matching it.) It doesn't, it needs to be specified in one place. Distros will need to update boot parameter handling for this kernel onwards. Otherwise, we will need to carry this confusing mess forward forever. > The LSM order needs to be defined externally to enablement because > something may become enabled when not listed in the order. > > Now, maybe I misunderstood your earlier suggestion, and what you meant > was to do something like: > > CONFIG_LSM="yama,apparmor,!selinux" > > to mean "put selinux here in the order, but don't enable it". Then the > problem becomes what happens to an LSM that has been built in but not > listed in CONFIG_LSM? In my most recent suggestion, there is no '!' disablement, just enablement. If an LSM is not listed in CONFIG_LSM="", it's not enabled. > Related to that, this means that when new LSMs are added, they will > need to be added to any custom CONFIG_LSM= or lsm= parameters. If > that's really how we have to go, I'll accept it, but I think it's a > bit unfriendly. :P If you want to enable them, yes. How is this different to adding new mount options as new fs features become available? > Another reason I don't like it is because it requires users to know > about all the LSMs to make changes. One LSM can't be added/removed > without specifying ALL of the LSMs. (i.e. there is no trivial way to > enable/disable a single LSM without it growing its own enable/disable > code as in SELinux/AppArmor. I'd hoped to make that easier for both > users and developers.) Again, I can live with it, but I think it's > unfriendly. This is only done via boot params or KConfig. -- James Morris From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from namei.org ([65.99.196.166]:35682 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727458AbeJEAoZ (ORCPT ); Thu, 4 Oct 2018 20:44:25 -0400 Date: Fri, 5 Oct 2018 03:49:14 +1000 (AEST) From: James Morris Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter In-Reply-To: Message-ID: References: <20181002005505.6112-1-keescook@chromium.org> <809f1cfd-077b-ee58-51ba-b22daf46d12b@tycho.nsa.gov> <5955f5ce-b803-4f58-8b07-54c291e33da5@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook Cc: John Johansen , Jordan Glover , Stephen Smalley , Paul Moore , Casey Schaufler , Tetsuo Handa , "Schaufler, Casey" , linux-security-module , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML Message-ID: <20181004174914.e_-sD2feEZKKLfWi8BWz4KMBnVWwtB7T2Dn6BVJkEk8@z> On Wed, 3 Oct 2018, Kees Cook wrote: > On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote: > > On Wed, 3 Oct 2018, Kees Cook wrote: > > > > - All LSMs which are built are NOT enabled by default > > > > - You specify enablement and order via a Kconfig: > > > > CONFIG_LSM="selinux,yama" > > > > - This can be entirely overridden by a boot param: > > > > lsm="apparmor,landlock" > > This doesn't work with how SELinux and AppArmor do their bootparams, > unfortunately. (And Paul and Stephen have expressed that the > documented selinux on/off must continue to work.) For example, let's > say you've built an Ubuntu kernel with: > > CONFIG_SELINUX=y > ... > CONFIG_LSM="yama,apparmor" > > (i.e. you want SELinux available, but not enabled, so it's left out of > CONFIG_LSM) > > Then someone boots the system with: > > selinux=1 security=selinux > > In what order does selinux get initialized relative to yama? > (apparmor, flagged as a "legacy major", would have been disabled by > the "security=" not matching it.) It doesn't, it needs to be specified in one place. Distros will need to update boot parameter handling for this kernel onwards. Otherwise, we will need to carry this confusing mess forward forever. > The LSM order needs to be defined externally to enablement because > something may become enabled when not listed in the order. > > Now, maybe I misunderstood your earlier suggestion, and what you meant > was to do something like: > > CONFIG_LSM="yama,apparmor,!selinux" > > to mean "put selinux here in the order, but don't enable it". Then the > problem becomes what happens to an LSM that has been built in but not > listed in CONFIG_LSM? In my most recent suggestion, there is no '!' disablement, just enablement. If an LSM is not listed in CONFIG_LSM="", it's not enabled. > Related to that, this means that when new LSMs are added, they will > need to be added to any custom CONFIG_LSM= or lsm= parameters. If > that's really how we have to go, I'll accept it, but I think it's a > bit unfriendly. :P If you want to enable them, yes. How is this different to adding new mount options as new fs features become available? > Another reason I don't like it is because it requires users to know > about all the LSMs to make changes. One LSM can't be added/removed > without specifying ALL of the LSMs. (i.e. there is no trivial way to > enable/disable a single LSM without it growing its own enable/disable > code as in SELinux/AppArmor. I'd hoped to make that easier for both > users and developers.) Again, I can live with it, but I think it's > unfriendly. This is only done via boot params or KConfig. -- James Morris