From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Johansen Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter Date: Tue, 2 Oct 2018 14:11:03 -0700 Message-ID: <7741e4c1-cc54-4d04-a064-cb5388817058@canonical.com> 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> <125243f2-8532-c0c0-0b0e-d28b3ecb910e@canonical.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-GB Sender: linux-kernel-owner@vger.kernel.org To: Kees Cook Cc: Jordan Glover , Stephen Smalley , Paul Moore , James Morris , 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 10/02/2018 01:29 PM, Kees Cook wrote: > On Tue, Oct 2, 2018 at 12:47 PM, John Johansen > wrote: >> On 10/02/2018 12:17 PM, Kees Cook wrote: >>> I could define CONFIG_LSM_ENABLE as being "additive" to >>> SECURITY_APPARMOR_BOOTPARAM_VALUE and >>> SECURITY_SELINUX_BOOTPARAM_VALUE? >> >> Oh sure lets deal with my complaint about too many ways to configure >> this beast by adding yet another config option :P > > This is what v3 already does: SEC...BOOTPARAM_VALUE trumps ...LSM_ENABLE. > sure but I sent in a patch to kill SECURITY_APPARMOR_BOOTPARAM_VALUE because I really dislike the extra levels of config and getting rid of the SEC..BOOTPARAM_VALUE seems to be the easy way to fix it Now if only we can convince Paul and Stephen :) >> seriously though, please no. That just adds another layer of confusion >> even if it is only being foisted on the distro/builder > > You've already sent a patch removing > SECURITY_APPARMOR_BOOTPARAM_VALUE. If SELinux is fine to do that too, > then I think we'll be sorted out. I'll just need to make "lsm.enable=" > be an explicit list. (Do you have a problem with "lsm.disable=..." ?) > why yes, glad you asked If lsm.enabled is an explicit list lsm.disabled isn't required its a convenience option that can introduce confusion and conflicts. If both lsm.enabled and lsm.disabled are being used at the same time. I realize that some times the convenience of specifying lsm.disable=$LSM is easier than specifying an entire list of what should be enabled when you just want to disable a single LSM. I don't think the convenience is worth the potential confusion, but I don't feel strongly about it and realize others feel the other way. tldr: I can live with it, but don't like it if you are asking :) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from youngberry.canonical.com ([91.189.89.112]:46267 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727747AbeJCD4a (ORCPT ); Tue, 2 Oct 2018 23:56:30 -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> <125243f2-8532-c0c0-0b0e-d28b3ecb910e@canonical.com> From: John Johansen Message-ID: <7741e4c1-cc54-4d04-a064-cb5388817058@canonical.com> Date: Tue, 2 Oct 2018 14:11:03 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook Cc: Jordan Glover , Stephen Smalley , Paul Moore , James Morris , Casey Schaufler , Tetsuo Handa , "Schaufler, Casey" , linux-security-module , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML Message-ID: <20181002211103.HshfObWLpELkz4KFXfyixy0leC6hexCP5_EuoSYK1_U@z> On 10/02/2018 01:29 PM, Kees Cook wrote: > On Tue, Oct 2, 2018 at 12:47 PM, John Johansen > wrote: >> On 10/02/2018 12:17 PM, Kees Cook wrote: >>> I could define CONFIG_LSM_ENABLE as being "additive" to >>> SECURITY_APPARMOR_BOOTPARAM_VALUE and >>> SECURITY_SELINUX_BOOTPARAM_VALUE? >> >> Oh sure lets deal with my complaint about too many ways to configure >> this beast by adding yet another config option :P > > This is what v3 already does: SEC...BOOTPARAM_VALUE trumps ...LSM_ENABLE. > sure but I sent in a patch to kill SECURITY_APPARMOR_BOOTPARAM_VALUE because I really dislike the extra levels of config and getting rid of the SEC..BOOTPARAM_VALUE seems to be the easy way to fix it Now if only we can convince Paul and Stephen :) >> seriously though, please no. That just adds another layer of confusion >> even if it is only being foisted on the distro/builder > > You've already sent a patch removing > SECURITY_APPARMOR_BOOTPARAM_VALUE. If SELinux is fine to do that too, > then I think we'll be sorted out. I'll just need to make "lsm.enable=" > be an explicit list. (Do you have a problem with "lsm.disable=..." ?) > why yes, glad you asked If lsm.enabled is an explicit list lsm.disabled isn't required its a convenience option that can introduce confusion and conflicts. If both lsm.enabled and lsm.disabled are being used at the same time. I realize that some times the convenience of specifying lsm.disable=$LSM is easier than specifying an entire list of what should be enabled when you just want to disable a single LSM. I don't think the convenience is worth the potential confusion, but I don't feel strongly about it and realize others feel the other way. tldr: I can live with it, but don't like it if you are asking :)