[PATCH 04/10] CaitSith: Add header file.

[Tetsuo Handa]

On 2022/11/10 11:22, Kees Cook wrote:
> On November 9, 2022 3:57:06 PM PST, Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> wrote:
>> On 2022/11/09 23:48, Paul Moore wrote:
>>>                                             If there is a significant
>>> change, e.g. the overall kernel policy towards out-of-tree code, we
>>> can reconsider this policy but as of right now only upstream LSMs will
>>> have LSM ID tokens assigned to them; in-development LSMs are free to
>>> temporarily assign themselves an ID token (which may change when the
>>> LSM is merged upstream), and out-of-tree LSMs are free to do whatever
>>> they like with respect to their code, just as they do now.
>>
>> If in-development LSMs and out-of-tree LSMs cannot get a stable ID token,
>> developers cannot write and publish userspace tools which make use of ID
>> token. If ID collision happens by use of temporarily ID token, this token
>> is no longer an identifier. That is a pointless and needless constraint
>> for getting LSM modules created / tested / used.
> 
> You have to let this go. You aren't hearing us: this ID reservation process
> is not a problem for anyone but you. It is the same for all the syscalls
> that get added, and all the prctls, etc etc. This isn't a problem for userspace
> tools using those, and there won't be a problem here either.
> 
> We will not support out of tree code, so needing ID stability for out-of-tree
> LSMs isn't a valid argument.
> 

This ID reservation process is very much a problem for you all.

In https://lkml.kernel.org/r/CAHC9VhQGnEcoYeGpwbbXbMrG1dOvJ=2ohd4zPYoqBJK9p1mSjQ@mail.gmail.com ,
Paul said that it is becoming increasingly difficult for people to find time to
review potential new LSMs.

  >> Many modules
  >>
  >>     SimpleFlow （ 2016/04/21 https://lwn.net/Articles/684825/ ）
  >>     HardChroot （ 2016/07/29 https://lwn.net/Articles/695984/ ）
  >>     Checmate （ 2016/08/04 https://lwn.net/Articles/696344/ ）
  >>     LandLock （ 2016/08/25 https://lwn.net/Articles/698226/ ）
  >>     PTAGS （ 2016/09/29 https://lwn.net/Articles/702639/ ）
  >>     CaitSith （ 2016/10/21 https://lwn.net/Articles/704262/ ）
  >>     SafeName （ 2016/05/03 https://lwn.net/Articles/686021/ ）
  >>     WhiteEgret （ 2017/05/30 https://lwn.net/Articles/724192/ ）
  >>     shebang （ 2017/06/09 https://lwn.net/Articles/725285/ ）
  >>     S.A.R.A. （ 2017/06/13 https://lwn.net/Articles/725230/ ）
  >>
  >> are proposed 5 or 6 years ago, but mostly became silent...
  > 
  > At least one of those, Landlock, has been merged upstream and is now
  > available in modern released Linux Kernels.  As far as the other LSMs
  > are concerned, I don't recall there ever being significant interest
  > among other developers or users to warrant their inclusion upstream.
  > If the authors believe that has changed, or is simply not true, they
  > are always welcome to post their patches again for discussion, review,
  > and potential upstreaming.  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.

Actually, previous CaitSith proposal in 2016 at
https://lkml.kernel.org/r/1477054150-4772-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
died because nobody except John Johansen showed interest, and John could not
find time to review.

We are getting more and more difficult to get new LSM module in-tree.
An in-development code being remaining out-of-tree shall happen. And you are
declaring that we ignore LSM modules which cannot get enough interests.
That's horrible and unacceptable.

What I'm repeating since
https://lkml.kernel.org/r/2225aec6-f0f3-d38e-ee3c-6139a7c25a37@I-love.SAKURA.ne.jp is that

  You are making LSM interface more and more unattractive. The consequence would be
  "The LSM interface is dead. We will give up implementing as LSMs."

Quite simple.