Message-ID: <d1e5b74a-5161-4906-96eb-4987ff440d19@I-love.SAKURA.ne.jp>
Date: Sat, 7 Sep 2024 19:14:17 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Paul Moore <paul@...l-moore.com>
Cc: linux-security-module <linux-security-module@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>, tomoyo-dev-en@...ts.osdn.me,
        tomoyo-users-en@...ts.osdn.me,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] LSM: allow loadable kernel module based LSM modules

On 2024/09/06 23:24, Paul Moore wrote:
> On Fri, Sep 6, 2024 at 3:43 AM Tetsuo Handa
> <penguin-kernel@...ove.sakura.ne.jp> wrote:
>> If you ignore my concern, I have to NACK the static call changes you are
>> going to send in the upcoming merge window.
> 
> I'm not ignoring your concern, I've responded to your emails and
> patches on the topic over, and over, and over, and over again by
> trying to explain to you that your goal of supporting out-of-tree LSMs
> regardless of the impact to the upstream LSM effort is not something
> that is acceptable to the upstream LSM effort, or the Linux kernel in
> general.

I want LKM-based LSM support in order to allow one of in-tree LSMs (namely
TOMOYO) to be delivered to my intended users, for nobody can solve the
realities that commit 20510f2f4e2d ("security: Convert LSM into a static
interface") missed:

  how difficult/unrealistic for Linux users who are using prebuilt kernel
  packages provided by Linux distributors to replace their kernels

  how difficult for Linux distributors to allow their users to use in-tree
  LSM modules which that distributor is not familiar with [1] because Linux
  distributors are supposed to support kernel packages they built and
  shipped

  Linux distributors do not want to enable out-of-tree code due to upstream
  first policy, while Linux kernel development community can not afford
  accepting whatever proposed code due to limited resources

One of LSM developers commented me ( Mon, 22 Jul 2024 17:12:05 +0200
in off-list discusstion) about AKARI

  Ofcourse you found a way to hack it. You want me to curl bash pipe
  your kernel module code that disables certain protections and runs
  arbitrary hacks on my machine? No thank you!

  Ofcourse you change the memory mapping of data. You are misleading
  your users into trusting you and instead of contributing code and
  working with distros for your use case, you are shipping hacks and
  making noise without any constructive code contribution or alignment
  with distros for your use-case (below RHEL won't eneable it even
  if we had a proper API). 

and this patch is for following that comment. All concerns about updating
__ro_after_init data is gone if we move to a dual static call and linked
list based approach. I'm very very very sad that you did not respond to

  I think what you can do is send patches for an API for LKM based LSMs
  and have it merged before my series, I will work with the code I have
  and make LKM based LSMs work. If this work gets merged, and your
  use-case is accepted (I think I can speak for at least Kees [if not
  others] too here) we will help you if you get stuck with MAX_LSM_COUNT
  or a dual static call and linked list based approach.

in [2], and started saying "No" to this approach after you accepted
the static call changes. You are ignoring my concern!



Link: https://bugzilla.redhat.com/show_bug.cgi?id=542986 [1]
Link: https://lkml.kernel.org/r/CACYkzJ7ght66802wQFKzokfJKMKDOobYgeaCpu5Gx=iX0EuJVg@mail.gmail.com [2]

Powered by blists - more mailing lists