Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp99516imm; Thu, 20 Sep 2018 19:15:29 -0700 (PDT) X-Google-Smtp-Source: ANB0VdboqFusPYCuYcHQTi99kNqRZMECCS1wLnqgoTvCGxQ8LBnBFbxgxgz35IVbucQ/gBKp3O6o X-Received: by 2002:a62:cc41:: with SMTP id a62-v6mr43818919pfg.131.1537496129316; Thu, 20 Sep 2018 19:15:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537496129; cv=none; d=google.com; s=arc-20160816; b=Vr6FdueZQI/id9DduQKqG32Py7Jde4rhRx4DzRZ8XsSmF9BlAVB9MRuKpCrwGzK2cy /dTEpIHyXfXUJRG6pkTYCSbf/MAeP1IylAVw8ROOjNUlMJAvRK36HY40lu8IT+qdSgNH 9Lisvzo3zTp59RRdEeyX54Mf6jQsCK5dHQu3NMoxO7fFEfLODolhFbVtbwMj4Vdy9Oqp Gnqun6Ae7mEbDfMqRfJhRLo59S7gWotUE5We0Qoa38g+V4rQeOejqOeOuOFCAIY/+Wp2 Lp10O87s8J2fH/QY7cYFF5+/BnFPGwl3NLozGhmnEJqGgcZqAezSkJZ0xouF5mbp8lUO ghSg== 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=Dil7h2/Ko9xi/IbpbbFFSV/dP2g5NM7VWXhRhsWcUHA=; b=qRurWyooovtwsDLxvokSNA4dymCZDmSuZD1AHXRare6CN1jBt9WTB0pyufoWDgONqN BDNj+wPC3H3oI87KUQB5iyanUBBl6JrSppPQsNxm6eVaev2Yr23bbwd8rfIgsNP1pqgs os9j7jYhUQTfkb94d6Z4r/me31eGVhoQbluPc6412/+K6z4V4rZj18IhliOIW+ktt7p+ Im8HLIhJC9LdmP4ZuKDKXR0LHoxhoyqloc986f70KCo8p8XhuvhpFmxxexYKP4jBj5SX J3Qk/d8NyWBImccpDRWyf0uWo5EZnhADtGyPG9kdaDAkLGAFlYYbEtksph4ODQqIGV1U HHzQ== 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 d22-v6si4522734plj.139.2018.09.20.19.15.13; Thu, 20 Sep 2018 19:15:29 -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 S2388984AbeIUIBd (ORCPT + 99 others); Fri, 21 Sep 2018 04:01:33 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:38878 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725855AbeIUIBc (ORCPT ); Fri, 21 Sep 2018 04:01:32 -0400 Received: from static-50-53-48-205.bvtn.or.frontiernet.net ([50.53.48.205] helo=[10.8.192.6]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1g3Ay9-00009l-2p; Fri, 21 Sep 2018 02:14:57 +0000 Subject: Re: [PATCH security-next v2 26/26] LSM: Add all exclusive LSMs to ordered initialization To: Kees Cook Cc: Casey Schaufler , James Morris , Tetsuo Handa , Paul Moore , Stephen Smalley , "Schaufler, Casey" , LSM , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML References: <20180920162338.21060-1-keescook@chromium.org> <20180920162338.21060-27-keescook@chromium.org> <7d2cc28b-aee5-ee91-9362-f92f8ca30adc@schaufler-ca.com> <6c899d9e-45aa-8159-c402-b3c4d1936112@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: <74ecd4ec-491b-93d7-4e3f-46f92121130b@canonical.com> Date: Thu, 20 Sep 2018 19:14:47 -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 09/20/2018 07:05 PM, Kees Cook wrote: > On Thu, Sep 20, 2018 at 6:39 PM, John Johansen > wrote: >> On 09/20/2018 06:10 PM, Casey Schaufler wrote: >>> On 9/20/2018 5:45 PM, Kees Cook wrote: >>>> On Thu, Sep 20, 2018 at 5:25 PM, Casey Schaufler wrote: >>>>> On 9/20/2018 9:23 AM, Kees Cook wrote: >>>>>> config LSM_ORDER >>>>>> string "Default initialization order of builtin LSMs" >>>>>> - default "yama,loadpin,integrity" >>>>>> + default "yama,loadpin,integrity,selinux,smack,tomoyo,apparmor" >>>>> If I want to compile all the major modules into my kernel and use >>>>> AppArmor by default would I use >>>>> >>>>> default "yama,loadpin,integrity,apparmor,selinux,smack,tomoyo" >>>>> >>>>> or >>>>> >>>>> default "yama,loadpin,integrity,apparmor" >>>> I was expecting the former, but the latter will have the same result. >> >> t find having the two be equivalent violates expectations. At least >> when considering the end goal of full/extreme stacking, its trivially >> the same with current major lsms being exclusive > > This mixes "enablement" with "ordering", though, and I think the past > threads have shown this to be largely problematic. > > However, with CONFIG_LSM_ENABLED, we get the effect you're looking for, IIUC. no, I was just stating in a world where we have full stacking those two are not equivalent, as I would assume the order of any lsm not listed may end up being different. > >>>>> When we have "blob-sharing" how could I compile in tomoyo, >>>>> but exclude it without a boot line option? >>>> Ooh, yes, this series has no way to do that. Perhaps >>>> CONFIG_LSM_DISABLE in the same form as CONFIG_LSM_ORDER? I would >>>> totally remove LoadPin's CONFIG for this in favor it. >>> >>> I would generally prefer an optional CONFIG_LSM_ENABLE to >>> CONFIG_LSM_DISABLE, but I understand the logic behind your >>> approach. I would be looking for something like >>> >> +1 on the CONFIG_LSM_ENABLE ove DISABLE >> >>> CONFIG LSM_ENABLE >>> string "Default set of enabled LSMs" >>> default "" >>> >>> as opposed to >>> >>> CONFIG LSM_DISABLE >>> string "Default set of disabled LSMs" >>> default "" >>> >>> where an empty string is interpreted as "use 'em all" >>> in either case. > > Yes, I like CONFIG_LSM_ENABLE if "empty" means "enable all". Should > CONFIG_LSM_ENABLE replace all the other CONFIG-based LSM > enabling/disabling? I don't particularly like "empty" being "enable all". With that how would I disable all builtin lsms so that I just boot with capability. An option of all or even * is more explicit and leaves the empty set to mean disable everything > >>>>> When we have full stacking, how could I compile in selinux >>>>> but exclude it? >>>> Yup, same problem. Same suggested solution? >>>> >>>> Should lsm.enable/disable= also become a comma-separated list, or >>>> should I leave it as a multi-instance thing like I have it? >>> >>> I prefer the multi-instance >>> lsm.disable=selinux lsm.disable=yama >>> to the list >>> lsm.disable=selinux,yama >>> >>> but at this point I don't really care all that much. >> >> the comma separated list however is consistent with what is being >> done for default order > > Yeah, and it would match the new CONFIG_LSM_ENABLE. > > FWIW, it was tedious to type "lsm.enable" and "lsm.disable" over and > over when doing testing, so I almost prefer the comma separated list > at the end of the day. I'll ponder this a bit. > > -Kees >