From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40133.protonmail.ch ([185.70.40.133]:28376 "EHLO mail-40133.protonmail.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726783AbeJBXS3 (ORCPT ); Tue, 2 Oct 2018 19:18:29 -0400 Date: Tue, 02 Oct 2018 16:33:59 +0000 From: Jordan Glover Reply-To: Jordan Glover Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter Message-ID: In-Reply-To: <809f1cfd-077b-ee58-51ba-b22daf46d12b@tycho.nsa.gov> 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 Content-Transfer-Encoding: quoted-printable Sender: linux-arch-owner@vger.kernel.org List-ID: To: Stephen Smalley Cc: Kees Cook , 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: <20181002163359.aWQBmlVPZwigh-grzEiCJ9ETlKZfM1TiBG_6XM3V_c8@z> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday, October 2, 2018 4:57 PM, Stephen Smalley wr= ote: > On 10/02/2018 10:44 AM, Kees Cook wrote: > > > On Tue, Oct 2, 2018 at 6:42 AM, Stephen Smalley sds@tycho.nsa.gov wrote= : > > > > > On 10/02/2018 08:12 AM, Paul Moore wrote: > > > > > > > On Mon, Oct 1, 2018 at 9:04 PM Kees Cook keescook@chromium.org wrot= e: > > > > > > > > > Since LSM enabling is now centralized with CONFIG_LSM_ENABLE and > > > > > "lsm.enable=3D...", this removes the LSM-specific enabling logic = from > > > > > SELinux. > > > > > > > > > > Signed-off-by: Kees Cook keescook@chromium.org > > > > > > > > > > ----------------------------------------------- > > > > > > > > > > .../admin-guide/kernel-parameters.txt | 9 ------ > > > > > security/selinux/Kconfig | 29 ------------------- > > > > > security/selinux/hooks.c | 15 +--------- > > > > > 3 files changed, 1 insertion(+), 52 deletions(-) > > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt > > > > > b/Documentation/admin-guide/kernel-parameters.txt > > > > > index cf963febebb0..0d10ab3d020e 100644 > > > > > --- a/Documentation/admin-guide/kernel-parameters.txt > > > > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > > > > @@ -4045,15 +4045,6 @@ > > > > > loaded. An invalid security module name will be > > > > > treated > > > > > as if no module has been chosen. > > > > > > > > > > - selinux=3D [SELINUX] Disable or enable SELinux a= t boot time. > > > > > > > > > > > > > > > - Format: { "0" | "1" } > > > > > > > > > > > > > > > - See security/selinux/Kconfig help text. > > > > > > > > > > > > > > > - 0 -- disable. > > > > > > > > > > > > > > > - 1 -- enable. > > > > > > > > > > > > > > > - Default value is set via kernel config = option. > > > > > > > > > > > > > > > - If enabled at boot time, /selinux/disab= le can be > > > > > > > > > > > > > > > > > > > > used > > > > > > > > > > - later to disable prior to initial polic= y load. > > > > > > > > > > > > > > > > > > No comments yet on the rest of the patchset, but the subject line o= f > > > > this patch caught my eye and I wanted to comment quickly on this on= e > > > > ... > > > > Not a fan unfortunately. > > > > Much like the SELinux bits under /proc/self/attr, this is a user > > > > visible thing which has made its way into a lot of docs, scripts, a= nd > > > > minds; I believe removing it would be a big mistake. > > > > > > Yes, we can't suddenly break existing systems that had selinux=3D0 in= their > > > grub config. We have to retain the support. > > > > Is it okay to only support selinux=3D0 (instead of also selinux=3D1)? > > For Fedora/RHEL kernels, selinux=3D1 would be redundant since it is the > default. However, in other distros where SELinux is not the default, I > think they have documented selinux=3D1 as the way to enable SELinux. So > users may be relying on that as well. I don't think we can safely drop > support for either one. Sorry. It's always documented as: "selinux=3D1 security=3Dselinux" so security=3D = should still do the job and selinux=3D1 become no-op, no? Jordan