From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF445C64EB9 for ; Tue, 2 Oct 2018 18:57:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7D58C2064D for ; Tue, 2 Oct 2018 18:57:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D58C2064D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-security-module-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727203AbeJCBmj (ORCPT ); Tue, 2 Oct 2018 21:42:39 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:44487 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726508AbeJCBmj (ORCPT ); Tue, 2 Oct 2018 21:42:39 -0400 Received: from static-50-53-48-205.bvtn.or.frontiernet.net ([50.53.48.205] helo=[192.168.192.153]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1g7Prd-0008CC-Qh; Tue, 02 Oct 2018 18:57:46 +0000 Subject: Re: [PATCH security-next v4 23/32] selinux: Remove boot parameter To: Kees Cook , Jordan Glover Cc: Stephen Smalley , Paul Moore , James Morris , Casey Schaufler , Tetsuo Handa , "Schaufler, Casey" , linux-security-module , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML 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: John Johansen Openpgp: preference=signencrypt Autocrypt: addr=john.johansen@canonical.com; prefer-encrypt=mutual; keydata= xsFNBE5mrPoBEADAk19PsgVgBKkImmR2isPQ6o7KJhTTKjJdwVbkWSnNn+o6Up5knKP1f49E BQlceWg1yp/NwbR8ad+eSEO/uma/K+PqWvBptKC9SWD97FG4uB4/caomLEU97sLQMtnvGWdx rxVRGM4anzWYMgzz5TZmIiVTZ43Ou5VpaS1Vz1ZSxP3h/xKNZr/TcW5WQai8u3PWVnbkjhSZ PHv1BghN69qxEPomrJBm1gmtx3ZiVmFXluwTmTgJOkpFol7nbJ0ilnYHrA7SX3CtR1upeUpM a/WIanVO96WdTjHHIa43fbhmQube4txS3FcQLOJVqQsx6lE9B7qAppm9hQ10qPWwdfPy/+0W 6AWtNu5ASiGVCInWzl2HBqYd/Zll93zUq+NIoCn8sDAM9iH+wtaGDcJywIGIn+edKNtK72AM gChTg/j1ZoWH6ZeWPjuUfubVzZto1FMoGJ/SF4MmdQG1iQNtf4sFZbEgXuy9cGi2bomF0zvy BJSANpxlKNBDYKzN6Kz09HUAkjlFMNgomL/cjqgABtAx59L+dVIZfaF281pIcUZzwvh5+JoG eOW5uBSMbE7L38nszooykIJ5XrAchkJxNfz7k+FnQeKEkNzEd2LWc3QF4BQZYRT6PHHga3Rg ykW5+1wTMqJILdmtaPbXrF3FvnV0LRPcv4xKx7B3fGm7ygdoowARAQABzR1Kb2huIEpvaGFu c2VuIDxqb2huQGpqbXgubmV0PsLBegQTAQoAJAIbAwULCQgHAwUVCgkICwUWAgMBAAIeAQIX gAUCTo0YVwIZAQAKCRAFLzZwGNXD2LxJD/9TJZCpwlncTgYeraEMeDfkWv8c1IsM1j0AmE4V tL+fE780ZVP9gkjgkdYSxt7ecETPTKMaZSisrl1RwqU0oogXdXQSpxrGH01icu/2n0jcYSqY KggPxy78BGs2LZq4XPfJTZmHZGnXGq/eDr/mSnj0aavBJmMZ6jbiPz6yHtBYPZ9fdo8btczw P41YeWoIu26/8II6f0Xm3VC5oAa8v7Rd+RWZa8TMwlhzHExxel3jtI7IzzOsnmE9/8Dm0ARD 5iTLCXwR1cwI/J9BF/S1Xv8PN1huT3ItCNdatgp8zqoJkgPVjmvyL64Q3fEkYbfHOWsaba9/ kAVtBNz9RTFh7IHDfECVaToujBd7BtPqr+qIjWFadJD3I5eLCVJvVrrolrCATlFtN3YkQs6J n1AiIVIU3bHR8Gjevgz5Ll6SCGHgRrkyRpnSYaU/uLgn37N6AYxi/QAL+by3CyEFLjzWAEvy Q8bq3Iucn7JEbhS/J//dUqLoeUf8tsGi00zmrITZYeFYARhQMtsfizIrVDtz1iPf/ZMp5gRB niyjpXn131cm3M3gv6HrQsAGnn8AJru8GDi5XJYIco/1+x/qEiN2nClaAOpbhzN2eUvPDY5W 0q3bA/Zp2mfG52vbRI+tQ0Br1Hd/vsntUHO903mMZep2NzN3BZ5qEvPvG4rW5Zq2DpybWc7B TQROZqz6ARAAoqw6kkBhWyM1fvgamAVjeZ6nKEfnRWbkC94L1EsJLup3Wb2X0ABNOHSkbSD4 pAuC2tKF/EGBt5CP7QdVKRGcQzAd6b2c1Idy9RLw6w4gi+nn/d1Pm1kkYhkSi5zWaIg0m5RQ Uk+El8zkf5tcE/1N0Z5OK2JhjwFu5bX0a0l4cFGWVQEciVMDKRtxMjEtk3SxFalm6ZdQ2pp2 822clnq4zZ9mWu1d2waxiz+b5Ia4weDYa7n41URcBEUbJAgnicJkJtCTwyIxIW2KnVyOrjvk QzIBvaP0FdP2vvZoPMdlCIzOlIkPLgxE0IWueTXeBJhNs01pb8bLqmTIMlu4LvBELA/veiaj j5s8y542H/aHsfBf4MQUhHxO/BZV7h06KSUfIaY7OgAgKuGNB3UiaIUS5+a9gnEOQLDxKRy/ a7Q1v9S+Nvx+7j8iH3jkQJhxT6ZBhZGRx0gkH3T+F0nNDm5NaJUsaswgJrqFZkUGd2Mrm1qn KwXiAt8SIcENdq33R0KKKRC80Xgwj8Jn30vXLSG+NO1GH0UMcAxMwy/pvk6LU5JGjZR73J5U LVhH4MLbDggD3mPaiG8+fotTrJUPqqhg9hyUEPpYG7sqt74Xn79+CEZcjLHzyl6vAFE2W0kx lLtQtUZUHO36afFv8qGpO3ZqPvjBUuatXF6tvUQCwf3H6XMAEQEAAcLBXwQYAQoACQUCTmas +gIbDAAKCRAFLzZwGNXD2D/XD/0ddM/4ai1b+Tl1jznKajX3kG+MeEYeI4f40vco3rOLrnRG FOcbyyfVF69MKepie4OwoI1jcTU0ADecnbWnDNHpr0SczxBMro3bnrLhsmvjunTYIvssBZtB 4aVJjuLILPUlnhFqa7fbVq0ZQjbiV/rt2jBENdm9pbJZ6GjnpYIcAbPCCa/ffL4/SQRSYHXo hGiiS4y5jBTmK5ltfewLOw02fkexH+IJFrrGBXDSg6n2Sgxnn++NF34fXcm9piaw3mKsICm+ 0hdNh4afGZ6IWV8PG2teooVDp4dYih++xX/XS8zBCc1O9w4nzlP2gKzlqSWbhiWpifRJBFa4 WtAeJTdXYd37j/BI4RWWhnyw7aAPNGj33ytGHNUf6Ro2/jtj4tF1y/QFXqjJG/wGjpdtRfbt UjqLHIsvfPNNJq/958p74ndACidlWSHzj+Op26KpbFnmwNO0psiUsnhvHFwPO/vAbl3RsR5+ 0Ro+hvs2cEmQuv9r/bDlCfpzp2t3cK+rhxUqisOx8DZfz1BnkaoCRFbvvvk+7L/fomPntGPk qJciYE8TGHkZw1hOku+4OoM2GB5nEDlj+2TF/jLQ+EipX9PkPJYvxfRlC6dK8PKKfX9KdfmA IcgHfnV1jSn+8yH2djBPtKiqW0J69aIsyx7iV/03paPCjJh7Xq9vAzydN5U/UA== Organization: Canonical Message-ID: Date: Tue, 2 Oct 2018 11:57:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On 10/02/2018 09:54 AM, 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 still don't > 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. > Yeah I would really like to remove the potential confusion for the user. The user now has 4 kernel options to play with, and get confused by LSM= (I'll count apparmor.enabled= here as well) security= lsm.enabled= lsm.disabled= I really don't like this, it will be very confusing for users. I also think an authoritative list of what is enabled is easier for users than mixing a list of whats enabled with kernel config default settings. 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 If we have to have multiple kernel parameter, I prefer a behvior where if you hav conflicting kernel parameters specified apparmor=0 lsm.enabled=apparmor that the conflict is logged and the lsm is left disabled, as I think it is easier for users to understand than the overrides scheme of v3, and sans logging of the conflict is effectively what we had in the past apparmor=0 security=apparmor or apparmor=1 security=selinux would result in apparmor being disabed That being said I get we have a mess currently, and there really doesn't seem to be a good way to fix it. I think getting this right for the user is important enough that I am willing to break current apparmor userspace api. While apparmor=0 is documented we have also documented security=X for years and apparmor=0 isn't used too often so I think we can drop it to help clean this mess up abit. I am not going to Nak, or block on v3 behavior if that is considered the best path forward after this discussion/rant. > 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? > > John, with 4 not happening, do you prefer to not have 2 happen? > > With CONFIGs removed, then the boot time defaults are controlled by > CONFIG_LSM_ENABLE, but the boot params continue to work as before. > Only the use of the new lsm.enable= and lsm.disable= would override > the per-LSM boot params. This would clean up the build-time CONFIG > weirdness, and leave the existing boot params as before (putting us > functionally in between the v3 and v4 series). > I'm ambivalent. I really want to clean this up but atm it doesn't really look like 2 is going to provide much of a benefit. If you think it helps clean this up, do it. Regardless 1 is going to happen, and I will start updating documentation and try to get users moving away from using the apparmor= kernel parameter.