Received: by 2002:a05:7412:518d:b0:e2:908c:2ebd with SMTP id fn13csp368345rdb; Thu, 5 Oct 2023 08:13:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEY5VPY4PqM/vl1ln8iMVQ2/jgP6ZpmrOULgLPCGgBbUz2hulgH+4Htt/B2AF5cdsWrcZ4m X-Received: by 2002:a17:90b:46c7:b0:277:4b68:b93c with SMTP id jx7-20020a17090b46c700b002774b68b93cmr5389995pjb.4.1696518806938; Thu, 05 Oct 2023 08:13:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696518806; cv=none; d=google.com; s=arc-20160816; b=J+Ye2M/J238pZqyq0YnTjJi/KdtSwyqfsKd92tljW2wg46ksHgl6i+qpstBrggMMEP VE0iuzVquM4tOfKf6FX2sg1/Zqq43e6s3K6dnwSCNF744iWHrb0Uxub+sGP07VTSekmZ WPryYkRi3Asg0b8RmOqw+oMZryfwizFHmFzy++iDCeCJknIWCQ33IlS7oRYhFN0YAMI3 3INXwC3VTkf94PCghtLU7xvF37Zi6DEEL3+s8duHQ49iuZCx6AodG0n5Oy/UeAORbg0d ECGlHGYIE5NeMQuj/+lyn8B/+b5Ehjgs04kickTG/iahu/8SWHAq44TIe61NSu/4hsOh aX6A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=h13uls9MDoQy+3tVVg4uR9mLSDY9CJUtoVixYJ6sEGc=; fh=ll47VoWWVEqkkuj6V8zQm5NhVoIH3QNWSC48tgEQzCs=; b=V53dcSZk0tk/y+1NkWU0/HHsMxOv7BpGGgSSnx4VfVDFdI4ErqijTdwiqvWAviMjPu Uc7ZGtUD44dgywaT7igc9YA/cpDC0kN6hZSj8Pyxus0daxDEp9ZZZBqPjnuxs6vKPvCF Zc61S/EuqYDncY4MaNC3Dh9QYWZVFi4i9zUEzLtjQgjOc52qqZiB2m+nxsprDpPIFcT0 iNKuRsKbvS3j9wZa9bJt+CXNDp/VlZq567estLfMuXtbM7hcszWsKz5XhTvBvpQ+ZUWp CNQuBEEa7Q6CIEDcIlhExYsLc8En0kQgFFI5DXoWyuxorQuPGj8ewKnU2NZ+aD/LOmef ap6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id h7-20020a17090a2ec700b0026816382fdbsi1705822pjs.40.2023.10.05.08.13.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Oct 2023 08:13:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 71ED38705EBB; Thu, 5 Oct 2023 08:13:25 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230177AbjJEPNL (ORCPT + 99 others); Thu, 5 Oct 2023 11:13:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232198AbjJEPML (ORCPT ); Thu, 5 Oct 2023 11:12:11 -0400 Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 754176983; Thu, 5 Oct 2023 07:43:17 -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 395Cwfl1025108; Thu, 5 Oct 2023 21:58:41 +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); Thu, 05 Oct 2023 21:58:41 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav119.sakura.ne.jp) Received: from [192.168.1.6] (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 395CwfX9025104 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Oct 2023 21:58:41 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: Date: Thu, 5 Oct 2023 21:58:41 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v15 01/11] LSM: Identify modules by more than name Content-Language: en-US To: Casey Schaufler , paul@paul-moore.com, linux-security-module@vger.kernel.org Cc: jmorris@namei.org, serge@hallyn.com, keescook@chromium.org, john.johansen@canonical.com, stephen.smalley.work@gmail.com, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, mic@digikod.net References: <20230912205658.3432-1-casey@schaufler-ca.com> <20230912205658.3432-2-casey@schaufler-ca.com> From: Tetsuo Handa In-Reply-To: <20230912205658.3432-2-casey@schaufler-ca.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 05 Oct 2023 08:13:26 -0700 (PDT) On 2023/09/13 5:56, Casey Schaufler wrote: > Create a struct lsm_id to contain identifying information about Linux > Security Modules (LSMs). At inception this contains the name of the > module and an identifier associated with the security module. Change > the security_add_hooks() interface to use this structure. Change the > individual modules to maintain their own struct lsm_id and pass it to > security_add_hooks(). I came to worry about what purpose does the LSM ID value (or more precisely, "struct lsm_id") is used for. If the LSM ID value is used for only switch {reading,writing} /proc/self/attr/ of specific LSM module's information, only LSM modules that use /proc/self/attr/ will need the LSM ID value. But this series uses "struct lsm_id" as one of arguments for security_add_hooks(), and might be reused for different purposes. Then, BPF-based LSMs (which are not considered as in-tree LSM modules, for only BPF hook is considered as in-tree LSM module) might receive unfavorable treatment than non BPF-based LSMs? [PATCH v15 05/11] says Create a system call to report the list of Linux Security Modules that are active on the system. The list is provided as an array of LSM ID numbers. The calling application can use this list determine what LSM specific actions it might take. That might include choosing an output format, determining required privilege or bypassing security module specific behavior. but, at least, name of BPF-based LSMs won't be shown up in lsm_list_modules() compared to non BPF-based LSMs? Then, the calling application can't use this list determine what BPF-based LSM specific actions it might take?