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 11D8EC433FE for ; Wed, 26 Oct 2022 10:19:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231681AbiJZKTi (ORCPT ); Wed, 26 Oct 2022 06:19:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231937AbiJZKTh (ORCPT ); Wed, 26 Oct 2022 06:19:37 -0400 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79EAC10071 for ; Wed, 26 Oct 2022 03:19:36 -0700 (PDT) Received: from fsav313.sakura.ne.jp (fsav313.sakura.ne.jp [153.120.85.144]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 29QAJYGa040633; Wed, 26 Oct 2022 19:19:34 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav313.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav313.sakura.ne.jp); Wed, 26 Oct 2022 19:19:34 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav313.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 29QAJYCE040630 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Oct 2022 19:19:34 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <3266c2c2-cd7e-bc0f-0fc4-478a63d6ee77@I-love.SAKURA.ne.jp> Date: Wed, 26 Oct 2022 19:19:28 +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 To: Casey Schaufler , John Johansen , Paul Moore Cc: 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> <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> <5995f18c-5623-9d97-0aa6-5f13a2a8e895@I-love.SAKURA.ne.jp> <77ec837a-ff64-e6f0-fe14-a54c1646ea0b@canonical.com> <0fcc5444-a957-f107-25a1-3540588eab5a@I-love.SAKURA.ne.jp> <11564f69-3bba-abf7-eb46-06813ff4a404@schaufler-ca.com> <98ab33d6-6c91-9c0a-8647-22f6bdede885@I-love.SAKURA.ne.jp> From: Tetsuo Handa In-Reply-To: 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/26 7:41, Casey Schaufler wrote: > You need a built-in LSM that loads and manages loadable > security modules. That is no longer loadable LSM modules. A loadable LSM module must be capable of loading any code and using any interface that is allowed to loadable kernel modules using /sbin/insmod command. That is my understanding of what you have promised (and the reason I am allowing you to continue working on LSM stacking before I make CONFIG_SECURITY_TOMOYO=m). > That LSM would have an LSM ID just like the BPF LSM > has a LSM ID. There can't be a LSM that manages loadable security modules. TOMOYO can't be loaded via such LSM, for TOMOYO needs to e.g. create /sys/kernel/security/tomoyo/ interface. A contained program like BPF can't get such flexibility, and a LSM that manages loadable security modules can't manage flexible/unconfined programs. > That LSM would have an LSM ID just like the BPF LSM > has a LSM ID. Whatever LSM modules that are in-tree will have an LSM id. But you must remember that not all LSM modules are in-tree (and won't be able to get in-tree). The LSM id I'm talking about is for LSM modules that cannot get in-tree. > I have no doubt that there are multiple workable implementations, > as I have looked into many different ways to implement the stacking for > built-in modules. Please enumerate some that can satisfy our promise. Even if there is a LSM that manages loadable LSMs, loadable LSMs can't get LSM id because what loadable LSMs will do is beyond what the BPF LSM can do. Loadable LSMs by nature needs to be able to have unique identifier (currently module name, and you are trying to change from name to integer which some of loadable LSMs cannot get). > I am also sorry that I don't expect to have enough working > years left to even consider spending any more time on the problem. This is > a development effort for The Next Generation. If you segregate built-in LSM modules and loadable LSM modules (remember, not all LSM modules will be able to get in-tree and built-in), userspace won't be able to use LSM id you are trying to introduce. Your LSM id makes LSM framework worse than now. You are killing The Next Generation due to "only in-tree and supported by distributors is correct" crap. 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 5916EC433FE for ; Wed, 26 Oct 2022 10:20:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1666779602; 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=SNBkbn6Gw1YxYu5isqxx9DN4DOka+jzyfFF20JP8AFY=; b=eYpMrnMnrcit9V3ML06PEjCrlioBdRZQJKj6BrVkwYWLdGTEE5VY0zJjZeRPsuxA1qSHf8 22qL00/WJeHewuKVdAezuK9hV1MaQoO20Pg5q54hcWQRMAlaFGKGsNnbkN9+Hx6abhtX2H +pE/Q9E2ZomT7/AYYWHMZtkNfCJT/NQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-204-F_v5mK8FPcWwoy1_JyQcaQ-1; Wed, 26 Oct 2022 06:19:58 -0400 X-MC-Unique: F_v5mK8FPcWwoy1_JyQcaQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 482528027EC; Wed, 26 Oct 2022 10:19:57 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id C360840C2140; Wed, 26 Oct 2022 10:19:54 +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 9E26919465A4; Wed, 26 Oct 2022 10:19:54 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 7F4491946597 for ; Wed, 26 Oct 2022 10:19:53 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 6F1DA492B17; Wed, 26 Oct 2022 10:19:53 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast01.extmail.prod.ext.rdu2.redhat.com [10.11.55.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 665D6492B16 for ; Wed, 26 Oct 2022 10:19:53 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.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 49B7F85A5A6 for ; Wed, 26 Oct 2022 10:19:53 +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-503-os1eWn84NwecltyjEdMHkQ-1; Wed, 26 Oct 2022 06:19:51 -0400 X-MC-Unique: os1eWn84NwecltyjEdMHkQ-1 Received: from fsav313.sakura.ne.jp (fsav313.sakura.ne.jp [153.120.85.144]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 29QAJYGa040633; Wed, 26 Oct 2022 19:19:34 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav313.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav313.sakura.ne.jp); Wed, 26 Oct 2022 19:19:34 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav313.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 29QAJYCE040630 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Oct 2022 19:19:34 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: <3266c2c2-cd7e-bc0f-0fc4-478a63d6ee77@I-love.SAKURA.ne.jp> Date: Wed, 26 Oct 2022 19:19:28 +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? To: Casey Schaufler , John Johansen , Paul Moore References: <791e13b5-bebd-12fc-53de-e9a86df23836.ref@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> <5995f18c-5623-9d97-0aa6-5f13a2a8e895@I-love.SAKURA.ne.jp> <77ec837a-ff64-e6f0-fe14-a54c1646ea0b@canonical.com> <0fcc5444-a957-f107-25a1-3540588eab5a@I-love.SAKURA.ne.jp> <11564f69-3bba-abf7-eb46-06813ff4a404@schaufler-ca.com> <98ab33d6-6c91-9c0a-8647-22f6bdede885@I-love.SAKURA.ne.jp> From: Tetsuo Handa In-Reply-To: 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-Mimecast-Spam-Signature: yes X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 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: 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.1 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/26 7:41, Casey Schaufler wrote: > You need a built-in LSM that loads and manages loadable > security modules. That is no longer loadable LSM modules. A loadable LSM module must be capable of loading any code and using any interface that is allowed to loadable kernel modules using /sbin/insmod command. That is my understanding of what you have promised (and the reason I am allowing you to continue working on LSM stacking before I make CONFIG_SECURITY_TOMOYO=m). > That LSM would have an LSM ID just like the BPF LSM > has a LSM ID. There can't be a LSM that manages loadable security modules. TOMOYO can't be loaded via such LSM, for TOMOYO needs to e.g. create /sys/kernel/security/tomoyo/ interface. A contained program like BPF can't get such flexibility, and a LSM that manages loadable security modules can't manage flexible/unconfined programs. > That LSM would have an LSM ID just like the BPF LSM > has a LSM ID. Whatever LSM modules that are in-tree will have an LSM id. But you must remember that not all LSM modules are in-tree (and won't be able to get in-tree). The LSM id I'm talking about is for LSM modules that cannot get in-tree. > I have no doubt that there are multiple workable implementations, > as I have looked into many different ways to implement the stacking for > built-in modules. Please enumerate some that can satisfy our promise. Even if there is a LSM that manages loadable LSMs, loadable LSMs can't get LSM id because what loadable LSMs will do is beyond what the BPF LSM can do. Loadable LSMs by nature needs to be able to have unique identifier (currently module name, and you are trying to change from name to integer which some of loadable LSMs cannot get). > I am also sorry that I don't expect to have enough working > years left to even consider spending any more time on the problem. This is > a development effort for The Next Generation. If you segregate built-in LSM modules and loadable LSM modules (remember, not all LSM modules will be able to get in-tree and built-in), userspace won't be able to use LSM id you are trying to introduce. Your LSM id makes LSM framework worse than now. You are killing The Next Generation due to "only in-tree and supported by distributors is correct" crap. -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit