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=ham 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 E6EC1C43143 for ; Sat, 29 Sep 2018 18:20:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B12222073F for ; Sat, 29 Sep 2018 18:20:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B12222073F 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-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728656AbeI3At1 (ORCPT ); Sat, 29 Sep 2018 20:49:27 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:41272 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728197AbeI3At0 (ORCPT ); Sat, 29 Sep 2018 20:49:26 -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 1g6JqO-00039H-Oc; Sat, 29 Sep 2018 18:19:56 +0000 Subject: Re: [PATCH security-next v3 00/29] LSM: Explict LSM ordering To: Tetsuo Handa , Kees Cook , Casey Schaufler Cc: James Morris , Paul Moore , Stephen Smalley , "Schaufler, Casey" , LSM , Jonathan Corbet , "open list:DOCUMENTATION" , linux-arch , LKML References: <20180925001832.18322-1-keescook@chromium.org> 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: Sat, 29 Sep 2018 11:19:52 -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/29/2018 03:48 AM, Tetsuo Handa wrote: > On 2018/09/29 5:01, Kees Cook wrote: >> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler wrote: >>> On 9/24/2018 5:18 PM, Kees Cook wrote: >>>> v3: >>>> - add CONFIG_LSM_ENABLE and refactor resulting logic >>> >>> Kees, you can add my >>> >>> Reviewed-by:Casey Schaufler >>> >>> for this entire patch set. Thank you for taking this on, it's >>> a significant and important chunk of the LSM infrastructure >>> update. >> >> Thanks! >> >> John, you'd looked at this a bit too -- do the results line up with >> your expectations? >> >> Any thoughts from SELinux, TOMOYO, or IMA folks? > > I'm OK with this approach. Thank you. > > > > Just wondering what is "__lsm_name_##lsm" for... > > +#define DEFINE_LSM(lsm) \ > + static const char __lsm_name_##lsm[] __initconst \ > + __aligned(1) = #lsm; \ > + static struct lsm_info __lsm_##lsm \ > + __used __section(.lsm_info.init) \ > + __aligned(sizeof(unsigned long)) \ > + = { \ > + .name = __lsm_name_##lsm, \ > + > +#define END_LSM } > > We could do something like below so that funny END_LSM is not required? > I felt } like a typo error at the first glance. What we need is to > gather into one section with appropriate alignment, isn't it? > well and Kees was trying to automagically set the name. This threw me off too at first and I am still trying to figure out if I would prefer something simpler, and more standard like below. > #define LSM_INFO \ > static struct lsm_info __lsm_ \ > __used __section(.lsm_info.init) \ > __aligned(sizeof(unsigned long)) \ > > LSM_INFO = { > .name = "tomoyo", > .flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE, > .init = tomoyo_init, > }; > From mboxrd@z Thu Jan 1 00:00:00 1970 From: john.johansen@canonical.com (John Johansen) Date: Sat, 29 Sep 2018 11:19:52 -0700 Subject: [PATCH security-next v3 00/29] LSM: Explict LSM ordering In-Reply-To: References: <20180925001832.18322-1-keescook@chromium.org> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 09/29/2018 03:48 AM, Tetsuo Handa wrote: > On 2018/09/29 5:01, Kees Cook wrote: >> On Fri, Sep 28, 2018 at 8:55 AM, Casey Schaufler wrote: >>> On 9/24/2018 5:18 PM, Kees Cook wrote: >>>> v3: >>>> - add CONFIG_LSM_ENABLE and refactor resulting logic >>> >>> Kees, you can add my >>> >>> Reviewed-by:Casey Schaufler >>> >>> for this entire patch set. Thank you for taking this on, it's >>> a significant and important chunk of the LSM infrastructure >>> update. >> >> Thanks! >> >> John, you'd looked at this a bit too -- do the results line up with >> your expectations? >> >> Any thoughts from SELinux, TOMOYO, or IMA folks? > > I'm OK with this approach. Thank you. > > > > Just wondering what is "__lsm_name_##lsm" for... > > +#define DEFINE_LSM(lsm) \ > + static const char __lsm_name_##lsm[] __initconst \ > + __aligned(1) = #lsm; \ > + static struct lsm_info __lsm_##lsm \ > + __used __section(.lsm_info.init) \ > + __aligned(sizeof(unsigned long)) \ > + = { \ > + .name = __lsm_name_##lsm, \ > + > +#define END_LSM } > > We could do something like below so that funny END_LSM is not required? > I felt } like a typo error at the first glance. What we need is to > gather into one section with appropriate alignment, isn't it? > well and Kees was trying to automagically set the name. This threw me off too at first and I am still trying to figure out if I would prefer something simpler, and more standard like below. > #define LSM_INFO \ > static struct lsm_info __lsm_ \ > __used __section(.lsm_info.init) \ > __aligned(sizeof(unsigned long)) \ > > LSM_INFO = { > .name = "tomoyo", > .flags = LSM_FLAG_LEGACY_MAJOR | LSM_FLAG_EXCLUSIVE, > .init = tomoyo_init, > }; >