From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-f196.google.com ([209.85.219.196]:37784 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727030AbeJDAQC (ORCPT ); Wed, 3 Oct 2018 20:16:02 -0400 Received: by mail-yb1-f196.google.com with SMTP id h1-v6so2713716ybm.4 for ; Wed, 03 Oct 2018 10:26:41 -0700 (PDT) Received: from mail-yw1-f41.google.com (mail-yw1-f41.google.com. [209.85.161.41]) by smtp.gmail.com with ESMTPSA id x64-v6sm1445632ywx.103.2018.10.03.10.26.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Oct 2018 10:26:38 -0700 (PDT) Received: by mail-yw1-f41.google.com with SMTP id s73-v6so2602872ywg.11 for ; Wed, 03 Oct 2018 10:26:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <583a703e-18af-a1b2-dfc9-62a2a3384825@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> <5955f5ce-b803-4f58-8b07-54c291e33da5@canonical.com> <583a703e-18af-a1b2-dfc9-62a2a3384825@tycho.nsa.gov> From: Kees Cook Date: Wed, 3 Oct 2018 10:26:36 -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: John Johansen , James Morris , Jordan Glover , Paul Moore , Casey Schaufler , Tetsuo Handa , "Schaufler, Casey" , linux-security-module , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML Message-ID: <20181003172636.CrjAwlFYVqXxMa0Suy7GoIb-ncbe4HhFukA33-InHZg@z> On Wed, Oct 3, 2018 at 6:39 AM, Stephen Smalley wrote: > On 10/02/2018 07:54 PM, Kees Cook wrote: >> >> On Tue, Oct 2, 2018 at 4:46 PM, John Johansen >> wrote: >>> >>> On 10/02/2018 04:06 PM, Kees Cook wrote: >>>> >>>> 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 >>> >>> >>> Hrrmmm isn't this a Kconfig selectable list, with each built-in LSM >>> available to be enabled by default at boot. >> >> >> That's not how I have it currently. It's a comma-separated a string, >> including the reserved name "all". The default would just be >> "CONFIG_LSM_ENABLE=all". Casey and I wanted this to have a way to >> capture new LSMs by default at build-time. >> >>>> - Boot time enabling for selinux= and apparmor= remain >>>> - lsm.enable= is explicit: overrides above and omissions are disabled >>> >>> wfm >> >> >> Okay, this is closer to v3 than v4. Paul or Stephen, how do you feel >> about losing the SELinux bootparam CONFIG? (i.e. CONFIG_LSM_ENABLE >> would be replacing its functionality.) > > > I'd like to know how distro kernel maintainers feel about it. They would > need to understand that if they were previously setting > CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE to 0 and want to preserve that > behavior, then they must set CONFIG_LSM_ENABLE explicitly to a list of > security modules (that does not include selinux, of course). In practice, That's not how it would be done. See below... > this means that even the distros that choose to build all security modules > into their kernels must explicitly set CONFIG_LSM_ENABLE to a specific list > of security modules. So no one would use "all" in practice. This is why I had originally wanted to do CONFIG_LSM_DISABLE. Right now, distro kernel maintainers have two ways to trigger enablement: via the SELinux and AppArmor BOOTPARAM_VALUE _and_ DEFAULT_SECURITY (which is an implicit "enable" for Smack or TOMOYO). All the minors are on-if-built. So, really, the BOOTPARAM_VALUEs were only used for disabling. Distros would build what they wanted, then use DEFAULT_SECURITY for their desired major, and if their DEFAULT_SECURITY wasn't SELinux or AppArmor, they'd _also_ have to set those BOOTPARAM_VALUEs to 0. The goal of the series is to split this more cleanly between "enable" and "order": the way to handle the LSMs is to enable _everything_ and then set the desired init order: the first exclusive "wins". So I *do* think the default would be CONFIG_LSM_ENALBE=all, since it's CONFIG_LSM_ORDER= that effectively replaces CONFIG_DEFAULT_SECURITY. Either a distro builds a very specific subset of LSMs, or they build in all LSMs (for the user to choose from). In both cases, they set an explicit order, which defines which exclusive LSM get selected. AppArmor wants to drop BOOTPARAM_VALUE, which make sense, since it's even now redundant to CONFIG_DEFAULT_SECURITY. I think it makes sense to drop SELinux's BOOTPARAM_VALUE too. The current way to "enable" a major LSM is via CONFIG_DEFAULT_SECURITY. No sane distro kernel is going to set CONFIG_DEFAULT_SECURITY=selinux and CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0. If you wanted no major LSM (but still build them all in), you'd set CONFIG_DEFAULT_SECURITY="". -Kees -- Kees Cook Pixel Security