Re: [PATCH v15 01/11] LSM: Identify modules by more than name

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Casey Schaufler <casey@schaufler-ca.com>,
	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, Dave Chinner <david@fromorbit.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: [PATCH v15 01/11] LSM: Identify modules by more than name
Date: Wed, 20 Sep 2023 19:20:35 +0900	[thread overview]
Message-ID: <ec37cd2f-24ee-3273-c253-58d480569117@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <6df9f8b8-5653-09a5-ae0a-6526016abaff@schaufler-ca.com>

On 2023/09/18 1:38, Casey Schaufler wrote:
> On 9/15/2023 11:32 PM, Tetsuo Handa wrote:
>> +/**
>> + * struct lsm_id - Identify a Linux Security Module.
>> + * @lsm: name of the LSM, must be approved by the LSM maintainers
>>
>> Why can't you understand that "approved by the LSM maintainers" is a horrible
>> requirement for LSM modules which cannot become one of in-tree LSMs?
>>
>> One of reasons for not every proposed LSM module can become in-tree is out of
>> the LSM community's resources for reviewing/maintaining (or failure to acquire
>> attention from the LSM community enough to get reviewed).
>>
>> + * @id: LSM ID number from uapi/linux/lsm.h
>>
>> Since the LSM community cannot accept all of proposed LSMs due to limited resources,
>> the LSM community is responsible for allowing whatever proposed LSMs (effectively any
>> publicly available LSMs) to live as out-of-tree LSMs, by approving the LSM name and
>> assigning a permanent LSM ID number.
>>
>> The only exception the LSM community can refuse to approve/assign would be that the name
>> is not appropriate (e.g. a LSM module named "FuckYou") or the name is misleading (e.g.
>> "selinux+", "smock", "tomato", "apparmour"). Otherwise, no matter how many times you repeat
>> "we don't care out-of-tree LSMs" or "I do not intentionally plan to make life difficult for
>> the out-of-tree LSMs", this patch is intended to lock out out-of-tree LSMs.
> 
> That is a false statement. There is a huge difference between apathy and malice. 

Dave Chinner wrote at https://lkml.kernel.org/r/ZQo94mCzV7hOrVkh@dread.disaster.area
as a response to "We don't care about out of tree filesystems.":

  In this case, we most certainly do care. Downstream distros support
  all sorts of out of tree filesystems loaded via kernel modules, so a
  syscall that is used to uniquely identify a filesystem type to
  userspace *must* have a mechanism for the filesystem to provide that
  unique identifier to userspace.

  Fundamentally, the kernel does not and should not dictate what
  filesystem types it supports; the user decides what filesystem they
  need to use, and it is the kernel's job to provide infrastructure
  that works with that user's choice.

Can you see? What you are trying to is NACKed by simple s/filesystem/LSM/g .

The kernel is ultimately there for users. The kernel is never there for doing patent
acquisition competition. If the LSM community accepts only LSMs which won the patent
acquisition competition as in-tree (as described in "ANN: new LSM guidelines"),
the LSM community is responsible for allowing any publicly available LSMs to live as
out of tree modules.

Unless the policy is updated to approve any publicly available LSMs and assign a unique
identifier (which can be passed to the syscalls introduced by this series) to each
publicly available LSM, this series is a regression.

The "[PATCH v15 01/11] LSM: Identify modules by more than name" is exactly doing
"LSM: allow only in-tree LSM modules, lock out out-of-tree LSM modules".
Nack, Nack, Nack, Nack, Nack!!!!!

> 
>>
>> + *
>> + * Contains the information that identifies the LSM.
>> + */
>> +struct lsm_id {
>> +	const char	*name;
>> +	u64		id;
>> +};
>>
>> Therefore, unless you change the policy for assigning LSM ID, I keep NACK on this change.
>>