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: Tue, 2 Oct 2018 16:06:25 -0700 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" 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 Tue, Oct 2, 2018 at 3:06 PM, James Morris wrote: > On Tue, 2 Oct 2018, Kees Cook wrote: > >> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen >> wrote: >> > Under the current scheme >> > >> > lsm.enabled=selinux >> > >> > could actually mean selinux,yama,loadpin,something_else are >> > enabled. If we extend this behavior to when full stacking lands >> > >> > lsm.enabled=selinux,yama >> > >> > might mean selinux,yama,apparmor,loadpin,something_else >> > >> > and what that list is will vary from kernel to kernel, which I think >> > is harder for the user than the lsm.enabled list being what is >> > actually enabled at boot >> >> Ah, I think I missed this in your earlier emails. What you don't like >> here is that "lsm.enable=" is additive. You want it to be explicit. >> > > This is a path to madness. > > How about enable flags set ONLY per LSM: > > lsm.selinux.enable=x > lsm.apparmor.enable=x > > With no lsm.enable, and removing selinux=x and apparmor=x. > > Yes this will break existing docs, but they can be updated for newer > kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from > kernel X onwards. > > Surely distro packages and bootloaders are able to cope with changes to > kernel parameters? > > We can either take a one-time hit now, or build new usability debt, which > will confuse people forever. I'd like to avoid this for a few reasons: - this requires per-LSM plumbing instead of centralized plumbing - each LSM needs to have its own CONFIG flag - each LSM needs to have its own bootparam flag - SELinux has explicited stated they do not want to lose selinux= - this doesn't meet John's goal of having a "single explicit enable list" I think the current proposal (in the other thread) is likely the sanest approach: - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE - Boot time enabling for selinux= and apparmor= remain - lsm.enable= is explicit: overrides above and omissions are disabled - maybe include lsm.disable= to disable anything -Kees -- Kees Cook Pixel Security From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f68.google.com ([209.85.161.68]:44029 "EHLO mail-yw1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727009AbeJCFwO (ORCPT ); Wed, 3 Oct 2018 01:52:14 -0400 Received: by mail-yw1-f68.google.com with SMTP id j75-v6so1512312ywj.10 for ; Tue, 02 Oct 2018 16:06:30 -0700 (PDT) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com. [209.85.219.179]) by smtp.gmail.com with ESMTPSA id l30-v6sm17946393ywa.104.2018.10.02.16.06.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Oct 2018 16:06:27 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id u88-v6so1582355ybi.0 for ; Tue, 02 Oct 2018 16:06:26 -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 16:06:25 -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: <20181002230625.Lb2MaSwQuA4BbXnEU9htx91EV-9L_ecQrPP8U6I160g@z> On Tue, Oct 2, 2018 at 3:06 PM, James Morris wrote: > On Tue, 2 Oct 2018, Kees Cook wrote: > >> On Tue, Oct 2, 2018 at 11:57 AM, John Johansen >> wrote: >> > Under the current scheme >> > >> > lsm.enabled=selinux >> > >> > could actually mean selinux,yama,loadpin,something_else are >> > enabled. If we extend this behavior to when full stacking lands >> > >> > lsm.enabled=selinux,yama >> > >> > might mean selinux,yama,apparmor,loadpin,something_else >> > >> > and what that list is will vary from kernel to kernel, which I think >> > is harder for the user than the lsm.enabled list being what is >> > actually enabled at boot >> >> Ah, I think I missed this in your earlier emails. What you don't like >> here is that "lsm.enable=" is additive. You want it to be explicit. >> > > This is a path to madness. > > How about enable flags set ONLY per LSM: > > lsm.selinux.enable=x > lsm.apparmor.enable=x > > With no lsm.enable, and removing selinux=x and apparmor=x. > > Yes this will break existing docs, but they can be updated for newer > kernel versions to say "replace selinux=0 with lsm.selinux.enable=0" from > kernel X onwards. > > Surely distro packages and bootloaders are able to cope with changes to > kernel parameters? > > We can either take a one-time hit now, or build new usability debt, which > will confuse people forever. I'd like to avoid this for a few reasons: - this requires per-LSM plumbing instead of centralized plumbing - each LSM needs to have its own CONFIG flag - each LSM needs to have its own bootparam flag - SELinux has explicited stated they do not want to lose selinux= - this doesn't meet John's goal of having a "single explicit enable list" I think the current proposal (in the other thread) is likely the sanest approach: - Drop CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE - Drop CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE - All enabled LSMs are listed at build-time in CONFIG_LSM_ENABLE - Boot time enabling for selinux= and apparmor= remain - lsm.enable= is explicit: overrides above and omissions are disabled - maybe include lsm.disable= to disable anything -Kees -- Kees Cook Pixel Security