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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 535D1FA3743 for ; Tue, 25 Oct 2022 09:48:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231361AbiJYJsO (ORCPT ); Tue, 25 Oct 2022 05:48:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231559AbiJYJsJ (ORCPT ); Tue, 25 Oct 2022 05:48:09 -0400 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F3473E087 for ; Tue, 25 Oct 2022 02:48:06 -0700 (PDT) Received: from fsav119.sakura.ne.jp (fsav119.sakura.ne.jp [27.133.134.246]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 29P9m5WX029474; Tue, 25 Oct 2022 18:48:05 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav119.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav119.sakura.ne.jp); Tue, 25 Oct 2022 18:48:05 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav119.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 29P9m4Ij029469 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Oct 2022 18:48:05 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <5995f18c-5623-9d97-0aa6-5f13a2a8e895@I-love.SAKURA.ne.jp> Date: Tue, 25 Oct 2022 18:48:01 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: LSM stacking in next for 6.1? Content-Language: en-US From: Tetsuo Handa To: Casey Schaufler , Paul Moore Cc: John Johansen , LSM List , James Morris , linux-audit@redhat.com, Mimi Zohar , keescook@chromium.org, SElinux list References: <791e13b5-bebd-12fc-53de-e9a86df23836.ref@schaufler-ca.com> <269014c6-5ce6-3322-5208-004cb1b40792@canonical.com> <1958a0d3-c4fb-0661-b516-93f8955cdb95@schaufler-ca.com> <6552af17-e511-a7d8-f462-cafcf41a33bb@schaufler-ca.com> <5ef4a1ae-e92c-ca77-7089-2efe1d4c4e6d@schaufler-ca.com> <1a9f9182-9188-2f64-4a17-ead2fed70348@schaufler-ca.com> <2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp> In-Reply-To: <2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org On 2022/10/25 1:37, Casey Schaufler wrote: >> What I'm insisting is that "warrant the freedom to load >> loadable LSM modules without recompiling the whole kernel". > > Since security modules are optional and the LSM infrastructure > itself is optional you can't ensure that any given kernel would > support a loadable security module. Like I propose adding EXPORT_SYMBOL_GPL(security_hook_heads), I'm not taking about distributors who choose CONFIG_SECURITY=n. >> Adding EXPORT_SYMBOL_GPL(security_hook_heads) is the only way that can "allow >> LSM modules which distributors cannot support to be legally loaded". > > I believe that I've identified an alternative. It isn't easy or cheap. No. You are just handwaving/postponing the problem using something unknown that is not yet shown as a workable code. Anything that can be disabled via kernel config option cannot be an alternative. Quoting from https://lkml.kernel.org/r/2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp > Like Paul Moore said > > However, I will caution that it is becoming increasingly difficult for people > to find time to review potential new LSMs so it may a while to attract sufficient > comments and feedback. > > , being unable to legally use loadable LSMs deprives of chances to develop/try > new LSMs, and makes LSM interface more and more unattractive. The consequence > would be "The LSM interface is dead. We will give up implementing as LSMs." The biggest problem is that quite few developers show interest in loadable LSM modules. How many developers responded to this topic? Once the ability to allow loadable LSM modules is technically lost, nobody shall be able to revive it. You will be happy with ignoring poor people. You are already and completely trapped into "only in-tree and supported by distributors is correct" crap. > Of course the upstream kernel isn't going to have LSM IDs for out-of-tree > security modules. That's one of many reasons loadable modules are going to > have to be treated differently from built-in modules, if they're allowed > at all. Then, I have to hate your idea of having fixed sized array. Nacked-by: Tetsuo Handa 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 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 267F8FA3741 for ; Tue, 25 Oct 2022 09:48:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666691324; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=WZJbd7pyfIO7mbjnR12I4l8uHXP4CRl2LWJ9kD1x0H4=; b=Ca6htr50/fasidRm0+WeCtFcph9MOLaq0d8uVFsblR9Qlun0gvIw42NDoB9100dro+llsJ Wg8X8sb1BgKkPQbDljwcUePWVKGIaIFf91jRIRiyEmp2mO7uB5lA64UOwU1OWZwU7oMsyi 9QnOJ3zdhO//VjqKmne+iCql7bCEDa4= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-518-OujWAPHnMIywG1MsUPpg7g-1; Tue, 25 Oct 2022 05:48:41 -0400 X-MC-Unique: OujWAPHnMIywG1MsUPpg7g-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 200023814946; Tue, 25 Oct 2022 09:48:39 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id A7F9F2166B31; Tue, 25 Oct 2022 09:48:37 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 8310F19465A4; Tue, 25 Oct 2022 09:48:37 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 51F921946597 for ; Tue, 25 Oct 2022 09:48:36 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 33B992166B36; Tue, 25 Oct 2022 09:48:36 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast02.extmail.prod.ext.rdu2.redhat.com [10.11.55.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2BE8B2166B31 for ; Tue, 25 Oct 2022 09:48:35 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C76E281F46A for ; Tue, 25 Oct 2022 09:48:30 +0000 (UTC) Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-302-sXTfUxPAOMqqoqNuY6zNrQ-1; Tue, 25 Oct 2022 05:48:22 -0400 X-MC-Unique: sXTfUxPAOMqqoqNuY6zNrQ-1 Received: from fsav119.sakura.ne.jp (fsav119.sakura.ne.jp [27.133.134.246]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 29P9m5WX029474; Tue, 25 Oct 2022 18:48:05 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav119.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav119.sakura.ne.jp); Tue, 25 Oct 2022 18:48:05 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav119.sakura.ne.jp) Received: from [192.168.1.9] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 29P9m4Ij029469 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Oct 2022 18:48:05 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <5995f18c-5623-9d97-0aa6-5f13a2a8e895@I-love.SAKURA.ne.jp> Date: Tue, 25 Oct 2022 18:48:01 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: LSM stacking in next for 6.1? From: Tetsuo Handa To: Casey Schaufler , Paul Moore References: <791e13b5-bebd-12fc-53de-e9a86df23836.ref@schaufler-ca.com> <269014c6-5ce6-3322-5208-004cb1b40792@canonical.com> <1958a0d3-c4fb-0661-b516-93f8955cdb95@schaufler-ca.com> <6552af17-e511-a7d8-f462-cafcf41a33bb@schaufler-ca.com> <5ef4a1ae-e92c-ca77-7089-2efe1d4c4e6d@schaufler-ca.com> <1a9f9182-9188-2f64-4a17-ead2fed70348@schaufler-ca.com> <2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp> In-Reply-To: <2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp> X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-BeenThere: linux-audit@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Audit Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: John Johansen , keescook@chromium.org, SElinux list , James Morris , Mimi Zohar , LSM List , linux-audit@redhat.com Errors-To: linux-audit-bounces@redhat.com Sender: "Linux-audit" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On 2022/10/25 1:37, Casey Schaufler wrote: >> What I'm insisting is that "warrant the freedom to load >> loadable LSM modules without recompiling the whole kernel". > > Since security modules are optional and the LSM infrastructure > itself is optional you can't ensure that any given kernel would > support a loadable security module. Like I propose adding EXPORT_SYMBOL_GPL(security_hook_heads), I'm not taking about distributors who choose CONFIG_SECURITY=n. >> Adding EXPORT_SYMBOL_GPL(security_hook_heads) is the only way that can "allow >> LSM modules which distributors cannot support to be legally loaded". > > I believe that I've identified an alternative. It isn't easy or cheap. No. You are just handwaving/postponing the problem using something unknown that is not yet shown as a workable code. Anything that can be disabled via kernel config option cannot be an alternative. Quoting from https://lkml.kernel.org/r/2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp > Like Paul Moore said > > However, I will caution that it is becoming increasingly difficult for people > to find time to review potential new LSMs so it may a while to attract sufficient > comments and feedback. > > , being unable to legally use loadable LSMs deprives of chances to develop/try > new LSMs, and makes LSM interface more and more unattractive. The consequence > would be "The LSM interface is dead. We will give up implementing as LSMs." The biggest problem is that quite few developers show interest in loadable LSM modules. How many developers responded to this topic? Once the ability to allow loadable LSM modules is technically lost, nobody shall be able to revive it. You will be happy with ignoring poor people. You are already and completely trapped into "only in-tree and supported by distributors is correct" crap. > Of course the upstream kernel isn't going to have LSM IDs for out-of-tree > security modules. That's one of many reasons loadable modules are going to > have to be treated differently from built-in modules, if they're allowed > at all. Then, I have to hate your idea of having fixed sized array. Nacked-by: Tetsuo Handa -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit