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: Thu, 4 Oct 2018 07:34:38 +1000 (AEST) Message-ID: References: <20181002005505.6112-1-keescook@chromium.org> <785ef6a9-ae46-3533-0348-74bcf6f10928@tycho.nsa.gov> <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 11:28 AM, James Morris wrote: > > On Wed, 3 Oct 2018, Kees Cook wrote: > > > >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote: > >> > On Tue, 2 Oct 2018, John Johansen wrote: > >> >> To me a list like > >> >> lsm.enable=X,Y,Z > >> > > >> > What about even simpler: > >> > > >> > lsm=selinux,!apparmor,yama > >> > >> We're going to have lsm.order=, so I'd like to keep it with a dot > >> separator (this makes it more like module parameters, too). You want > >> to mix enable/disable in the same string? That implies you'd want > >> implicit enabling (i.e. it complements the builtin enabling), which is > >> opposite from what John wanted. > >> > > > > Why can't this be the order as well? > > That was covered extensively in the earlier threads. It boils down to > making sure we do not create a pattern of leaving LSMs disabled by > default when they are added to the kernel. The v1 series used > security= like this: > > + security= [SECURITY] An ordered comma-separated list of > + security modules to attempt to enable at boot. If > + this boot parameter is not specified, only the > + security modules asking for initialization will be > + enabled (see CONFIG_DEFAULT_SECURITY). Duplicate > + or invalid security modules will be ignored. The > + capability module is always loaded first, without > + regard to this parameter. > > This meant booting "security=apparmor" would disable all the other > LSMs, which wasn't friendly at all. So "security=" was left alone (to > leave it to only select the "major" LSM: all major LSMs not matching > "security=" would be disabled). So I proposed "lsm.order=" to specify > the order things were going to be initialized in, but to avoid kernels > booting with newly added LSMs forced-off due to not being listed in > "lsm.order=", it had to have implicit fall-back for unlisted LSMs. > (i.e. anything missing from lsm.order would then follow their order in > CONFIG_LSM_ORDER, and anything missing there would fall back to > link-time ordering.) However, then the objection was raised that this > didn't provide a way to explicitly disable an LSM. So I proposed > lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over > CONFIG_LSM_DISABLE. Ok, but it may end up being clearer, simpler, and thus more secure to just have a single way to configure LSM. For example: - 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" And that's it. Of course, capabilities is always enabled and not be visible to kconfig or boot params. -- James Morris From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from namei.org ([65.99.196.166]:35550 "EHLO namei.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725799AbeJDEZO (ORCPT ); Thu, 4 Oct 2018 00:25:14 -0400 Date: Thu, 4 Oct 2018 07:34:38 +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> <785ef6a9-ae46-3533-0348-74bcf6f10928@tycho.nsa.gov> <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: <20181003213438.uQQMUFf56KDl72Z1eJp95Ad2pY1Olp77Wj46eJkuBjg@z> On Wed, 3 Oct 2018, Kees Cook wrote: > On Wed, Oct 3, 2018 at 11:28 AM, James Morris wrote: > > On Wed, 3 Oct 2018, Kees Cook wrote: > > > >> On Wed, Oct 3, 2018 at 11:17 AM, James Morris wrote: > >> > On Tue, 2 Oct 2018, John Johansen wrote: > >> >> To me a list like > >> >> lsm.enable=X,Y,Z > >> > > >> > What about even simpler: > >> > > >> > lsm=selinux,!apparmor,yama > >> > >> We're going to have lsm.order=, so I'd like to keep it with a dot > >> separator (this makes it more like module parameters, too). You want > >> to mix enable/disable in the same string? That implies you'd want > >> implicit enabling (i.e. it complements the builtin enabling), which is > >> opposite from what John wanted. > >> > > > > Why can't this be the order as well? > > That was covered extensively in the earlier threads. It boils down to > making sure we do not create a pattern of leaving LSMs disabled by > default when they are added to the kernel. The v1 series used > security= like this: > > + security= [SECURITY] An ordered comma-separated list of > + security modules to attempt to enable at boot. If > + this boot parameter is not specified, only the > + security modules asking for initialization will be > + enabled (see CONFIG_DEFAULT_SECURITY). Duplicate > + or invalid security modules will be ignored. The > + capability module is always loaded first, without > + regard to this parameter. > > This meant booting "security=apparmor" would disable all the other > LSMs, which wasn't friendly at all. So "security=" was left alone (to > leave it to only select the "major" LSM: all major LSMs not matching > "security=" would be disabled). So I proposed "lsm.order=" to specify > the order things were going to be initialized in, but to avoid kernels > booting with newly added LSMs forced-off due to not being listed in > "lsm.order=", it had to have implicit fall-back for unlisted LSMs. > (i.e. anything missing from lsm.order would then follow their order in > CONFIG_LSM_ORDER, and anything missing there would fall back to > link-time ordering.) However, then the objection was raised that this > didn't provide a way to explicitly disable an LSM. So I proposed > lsm.enable/disable, and John argued for CONFIG_LSM_ENABLE over > CONFIG_LSM_DISABLE. Ok, but it may end up being clearer, simpler, and thus more secure to just have a single way to configure LSM. For example: - 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" And that's it. Of course, capabilities is always enabled and not be visible to kconfig or boot params. -- James Morris