From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Smalley Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter Date: Tue, 2 Oct 2018 14:33:35 -0400 Message-ID: References: <20181002005505.6112-1-keescook@chromium.org> <20181002005505.6112-24-keescook@chromium.org> <785ef6a9-ae46-3533-0348-74bcf6f10928@tycho.nsa.gov> <809f1cfd-077b-ee58-51ba-b22daf46d12b@tycho.nsa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Kees Cook , Jordan Glover Cc: Paul Moore , James Morris , Casey Schaufler , John Johansen , Tetsuo Handa , "Schaufler, Casey" , linux-security-module , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML List-Id: linux-arch.vger.kernel.org On 10/02/2018 12:54 PM, Kees Cook wrote: > On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover > wrote: >> It's always documented as: "selinux=1 security=selinux" so security= should >> still do the job and selinux=1 become no-op, no? > > The v3 patch set worked this way, yes. (The per-LSM enable defaults > were set by the LSM. Only in the case of "lsm.disable=selinux" would > the above stop working.) > > John did not like the separation of having two CONFIG and two > bootparams mixing the controls. The v3 resolution rules were: > > SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE. > SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE. > selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE. > apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE. > apparmor= overrides apparmor.enabled=. > lsm.enable= overrides selinux=. > lsm.enable= overrides apparmor=. > lsm.disable= overrides lsm.enable=. > major LSM _omission_ from security= (if present) overrides lsm.enable. > > v4 removed the per-LSM boot params and CONFIGs at John's request, but > Paul and Stephen don't want this for SELinux. > > The pieces for reducing conflict with CONFIG_LSM_ENABLE and > lsm.{enable,disable}= were: > > 1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE. > 2- Remove apparmor= and apparmor.enabled=. > 3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE. > 4- Remove selinux=. > > v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too > commonly used. Would 3 be okay for SELinux? Let's say a user/packager/distro has been building kernels for the past 14 years (*) with a config that has SECURITY_SELINUX_BOOTPARAM_VALUE=0, and now they build a new kernel that includes these patches using that same config. Won't SELinux be enabled by default because SECURITY_SELINUX_BOOTPARAM_VALUE is now ignored and LSM_ENABLE defaults to all? Is it ok to require them to specify a new config option to preserve old behavior? (*) how long this config option has been around > > John, with 4 not happening, do you prefer to not have 2 happen? > > With CONFIGs removed, then the boot time defaults are controlled by > CONFIG_LSM_ENABLE, but the boot params continue to work as before. > Only the use of the new lsm.enable= and lsm.disable= would override > the per-LSM boot params. This would clean up the build-time CONFIG > weirdness, and leave the existing boot params as before (putting us > functionally in between the v3 and v4 series). > > -Kees > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uphb19pa13.eemsg.mail.mil ([214.24.26.87]:32938 "EHLO usfb19pa16.eemsg.mail.mil" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726293AbeJCBQ0 (ORCPT ); Tue, 2 Oct 2018 21:16:26 -0400 Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter References: <20181002005505.6112-1-keescook@chromium.org> <20181002005505.6112-24-keescook@chromium.org> <785ef6a9-ae46-3533-0348-74bcf6f10928@tycho.nsa.gov> <809f1cfd-077b-ee58-51ba-b22daf46d12b@tycho.nsa.gov> From: Stephen Smalley Message-ID: Date: Tue, 2 Oct 2018 14:33:35 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook , Jordan Glover Cc: Paul Moore , James Morris , Casey Schaufler , John Johansen , Tetsuo Handa , "Schaufler, Casey" , linux-security-module , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML Message-ID: <20181002183335.VBUiS_9hloRz3okcOeOzzyrJxiyNXUE4ie3iEAf3YL0@z> On 10/02/2018 12:54 PM, Kees Cook wrote: > On Tue, Oct 2, 2018 at 9:33 AM, Jordan Glover > wrote: >> It's always documented as: "selinux=1 security=selinux" so security= should >> still do the job and selinux=1 become no-op, no? > > The v3 patch set worked this way, yes. (The per-LSM enable defaults > were set by the LSM. Only in the case of "lsm.disable=selinux" would > the above stop working.) > > John did not like the separation of having two CONFIG and two > bootparams mixing the controls. The v3 resolution rules were: > > SECURITY_SELINUX_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE. > SECURITY_APPARMOR_BOOTPARAM_VALUE overrides CONFIG_LSM_ENABLE. > selinux= overrides SECURITY_SELINUX_BOOTPARAM_VALUE. > apparmor.enabled= overrides SECURITY_APPARMOR_BOOTPARAM_VALUE. > apparmor= overrides apparmor.enabled=. > lsm.enable= overrides selinux=. > lsm.enable= overrides apparmor=. > lsm.disable= overrides lsm.enable=. > major LSM _omission_ from security= (if present) overrides lsm.enable. > > v4 removed the per-LSM boot params and CONFIGs at John's request, but > Paul and Stephen don't want this for SELinux. > > The pieces for reducing conflict with CONFIG_LSM_ENABLE and > lsm.{enable,disable}= were: > > 1- Remove SECURITY_APPARMOR_BOOTPARAM_VALUE. > 2- Remove apparmor= and apparmor.enabled=. > 3- Remove SECURITY_SELINUX_BOOTPARAM_VALUE. > 4- Remove selinux=. > > v4 used all of 1-4 above. SELinux says "4" cannot happen as it's too > commonly used. Would 3 be okay for SELinux? Let's say a user/packager/distro has been building kernels for the past 14 years (*) with a config that has SECURITY_SELINUX_BOOTPARAM_VALUE=0, and now they build a new kernel that includes these patches using that same config. Won't SELinux be enabled by default because SECURITY_SELINUX_BOOTPARAM_VALUE is now ignored and LSM_ENABLE defaults to all? Is it ok to require them to specify a new config option to preserve old behavior? (*) how long this config option has been around > > John, with 4 not happening, do you prefer to not have 2 happen? > > With CONFIGs removed, then the boot time defaults are controlled by > CONFIG_LSM_ENABLE, but the boot params continue to work as before. > Only the use of the new lsm.enable= and lsm.disable= would override > the per-LSM boot params. This would clean up the build-time CONFIG > weirdness, and leave the existing boot params as before (putting us > functionally in between the v3 and v4 series). > > -Kees >