From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kees Cook Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter Date: Wed, 3 Oct 2018 16:55:31 -0700 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="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: James Morris 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, Oct 3, 2018 at 2:34 PM, James Morris wrote: > 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" 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.) 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? 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 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. I just want to have a direct I can go that meets all the requirements. :) I'm fine to ignore my sense of aesthetics if everyone can agree on the code. > And that's it. > > Of course, capabilities is always enabled and not be visible to kconfig or > boot params. Correct. I've made sure that's true in all the versions. BTW, there doesn't seem to be disagreement about the earlier part of the series, though (patches 1-10). Could these go into -next just so I don't have to keep sending them? :) LSM: Correctly announce start of LSM initialization vmlinux.lds.h: Avoid copy/paste of security_init section LSM: Rename .security_initcall section to .lsm_info LSM: Remove initcall tracing LSM: Convert from initcall to struct lsm_info vmlinux.lds.h: Move LSM_TABLE into INIT_DATA LSM: Convert security_initcall() into DEFINE_LSM() LSM: Record LSM name in struct lsm_info LSM: Provide init debugging infrastructure LSM: Don't ignore initialization failures Thanks! -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f65.google.com ([209.85.161.65]:43086 "EHLO mail-yw1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726182AbeJDGqM (ORCPT ); Thu, 4 Oct 2018 02:46:12 -0400 Received: by mail-yw1-f65.google.com with SMTP id j75-v6so3058342ywj.10 for ; Wed, 03 Oct 2018 16:55:35 -0700 (PDT) Received: from mail-yw1-f43.google.com (mail-yw1-f43.google.com. [209.85.161.43]) by smtp.gmail.com with ESMTPSA id w207-v6sm3536521yww.95.2018.10.03.16.55.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 16:55:33 -0700 (PDT) Received: by mail-yw1-f43.google.com with SMTP id d126-v6so3066165ywa.5 for ; Wed, 03 Oct 2018 16:55:32 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: 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> From: Kees Cook Date: Wed, 3 Oct 2018 16:55:31 -0700 Message-ID: Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: James Morris 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: <20181003235531.FsBh9KZmV5jqT6MtYWqEsEyDfa-X_YxV3zosUxr4cuU@z> On Wed, Oct 3, 2018 at 2:34 PM, James Morris wrote: > 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" 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.) 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? 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 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. I just want to have a direct I can go that meets all the requirements. :) I'm fine to ignore my sense of aesthetics if everyone can agree on the code. > And that's it. > > Of course, capabilities is always enabled and not be visible to kconfig or > boot params. Correct. I've made sure that's true in all the versions. BTW, there doesn't seem to be disagreement about the earlier part of the series, though (patches 1-10). Could these go into -next just so I don't have to keep sending them? :) LSM: Correctly announce start of LSM initialization vmlinux.lds.h: Avoid copy/paste of security_init section LSM: Rename .security_initcall section to .lsm_info LSM: Remove initcall tracing LSM: Convert from initcall to struct lsm_info vmlinux.lds.h: Move LSM_TABLE into INIT_DATA LSM: Convert security_initcall() into DEFINE_LSM() LSM: Record LSM name in struct lsm_info LSM: Provide init debugging infrastructure LSM: Don't ignore initialization failures Thanks! -Kees -- Kees Cook Pixel Security