From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ucol19pa09.eemsg.mail.mil ([214.24.24.82]:34604 "EHLO ucol19pa09.eemsg.mail.mil" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726966AbeJDCbs (ORCPT ); Wed, 3 Oct 2018 22:31:48 -0400 Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter References: <20181002005505.6112-1-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: Stephen Smalley Message-ID: Date: Wed, 3 Oct 2018 15:43:53 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook 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: <20181003194353.Ushm1RYz9cLFDU1o1Y4PbHsJ6C51a36tPoDhEKnO_4g@z> On 10/03/2018 01:26 PM, Kees Cook wrote: > 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="". Ok, then I have no objection to removing BOOTPARAM_VALUE.