From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f65.google.com ([209.85.161.65]:33284 "EHLO mail-yw1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727400AbeJCBrt (ORCPT ); Tue, 2 Oct 2018 21:47:49 -0400 Received: by mail-yw1-f65.google.com with SMTP id m127-v6so1238171ywb.0 for ; Tue, 02 Oct 2018 12:03:00 -0700 (PDT) Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com. [209.85.219.171]) by smtp.gmail.com with ESMTPSA id k189-v6sm3632506ywf.37.2018.10.02.12.02.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 12:03:00 -0700 (PDT) Received: by mail-yb1-f171.google.com with SMTP id e16-v6so1234483ybk.8 for ; Tue, 02 Oct 2018 12:02:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: 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: Kees Cook Date: Tue, 2 Oct 2018 12:02:58 -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: Stephen Smalley Cc: Jordan Glover , 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: <20181002190258.lFDut8YQ6pPJ2mTJTe5wf67svdMAxttCiWckptoow9s@z> On Tue, Oct 2, 2018 at 11:33 AM, Stephen Smalley wrote: > 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? Yes, I think that's fine -- kernel CONFIGs change all the time. System builders are used to examining these changes. -Kees -- Kees Cook Pixel Security