Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp674246imm; Mon, 1 Oct 2018 16:58:18 -0700 (PDT) X-Google-Smtp-Source: ACcGV63vna3PA8Jn0Wbo2a4abG5FHg/C2G4TOUcegB0dwsE8OsPKBx5IByAlu10SnBxTufGUSjlU X-Received: by 2002:a63:9409:: with SMTP id m9-v6mr10630880pge.93.1538438298888; Mon, 01 Oct 2018 16:58:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538438298; cv=none; d=google.com; s=arc-20160816; b=OcXfl5hmW3/lJoTAggMtc+PEwe5+w41O5qxrvTVdZek6mVtfwdoQd7HEVL6vg/zi6M TJmPcP1j0WyRZyqw2h71VnTHEN9xGkXO8rjWxPC68Tc9bHwHxShipZAzCnOSuNHIDEnl N8KS+2fCT4lNLnhAaciCUEubE6BnuWdf2wBDch02yEZWUV64jXX85Qg87tiLtb8YdpdV 6gN9mqwGbG9MNNtzJ6WhD6Ob57Gozwq9jcCGrye7TfqTWX+qjIf86O1DAbzd+655MpYR HX0FZll0CWtQsrA7bdVfVMFj9NuPctYng7so11H7U8mfn7zj5C/1lnZl6vKgBvUIJo/w ZASw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:autocrypt:openpgp:from:references:cc:to :subject; bh=Pb/vH3QrCeq+Cr3E6PcjyP6QHiRAJJ88Kokzve4S/QE=; b=yPFHOSazM685ZDad4dglTHa8NoDwlQkiKTUOYbI/LdfCLMq5rPedUITOegBv2Ip2W/ EdzSgUo937U6i7MK12V2sHbyUSOAnIoXcbh2Q0x0NKVGn57ONr6nAbPeQ1P+iRmoz4Fb M40o1STLI+kRyTvNMukTy89AujeCeoDRczb8x9S3ErqWBCLv8o4VeI5NXfteo2E4OzXU i2ezg29+QSykOI05g7KjSqTdvvd8dNpv1lsdQHkgXG1PZbKsndhP19Go7dSx+sObir6C CS4FlTcLg9c5yehItoZw9JLwX5VXgkU3PzdkM4iMkMSQzDHuvUzMUVCtr7uWiC/QeBOa DL6g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t2-v6si12855870plr.497.2018.10.01.16.58.01; Mon, 01 Oct 2018 16:58:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726521AbeJBGiQ (ORCPT + 99 others); Tue, 2 Oct 2018 02:38:16 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:52920 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726332AbeJBGiP (ORCPT ); Tue, 2 Oct 2018 02:38:15 -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 1g784Y-0006cR-UX; Mon, 01 Oct 2018 23:57:55 +0000 Subject: Re: [PATCH security-next v3 18/29] LSM: Introduce lsm.enable= and lsm.disable= To: Kees Cook Cc: Paul Moore , James Morris , Casey Schaufler , Tetsuo Handa , Stephen Smalley , "Schaufler, Casey" , LSM , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML References: <20180925001832.18322-1-keescook@chromium.org> <20180925001832.18322-19-keescook@chromium.org> <68e4e323-3216-7e77-2807-c3207126ae68@canonical.com> <9b3e1733-7cfa-5047-1422-0f9d92d88d39@canonical.com> 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: <0b6c66ab-7cfe-da99-40e7-d36a81ac79ef@canonical.com> Date: Mon, 1 Oct 2018 16:57:51 -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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/01/2018 04:38 PM, Kees Cook wrote: > On Mon, Oct 1, 2018 at 4:30 PM, Kees Cook wrote: >> If we keep it, "apparmor=0 lsm_enable=apparmor" would mean it's >> enabled. Is that okay? > > Actually, what the v3 series does right now is leaves AppArmor and > SELinux alone -- whatever they configured for enable/disable is left > alone. > > The problem I have is when processing CONFIG_LSM_ENABLE ... what do I > do with the existing "enable" flag? It's set by both > CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE and apparmor=0/1. > > Right now I can't tell the difference between someone booting with > apparmor=0 or CONFIG_LSM_ENABLE not including apparmor. > > i.e. how do I mix CONFIG_LSM_ENABLE with apparmor=0/1? (assuming > CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE has been removed) > right, Its a mess and confusing not just us but for the user. I think it is worth considering removing the apparmor= and apparmor.enabled options so that we can clean this up. If we do keep it, there are three options 1. last option wins (above) 2. add more states so we can track the different combination (more complex and probably not worth it) 3. we ignore any apparmor=1 (he default state) and only look at whether apparmor.enabled has been toggled to 0 during setup. At which point it stays that way. if we keep it, I think an explicit disable should win, so option 3, but I can live with 1.