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

[Kees Cook]

On Wed, Sep 20, 2023 at 07:20:35PM +0900, Tetsuo Handa wrote:
> 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@xxxxxxxxxxxxxxxxxxx
> 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!!!!!

I feel like you are willfully not listening to us when we say that this
doesn't block out of tree LSMs. Again, there is nothing here that stops
it. To prove this point, here is an out of tree LSM that works with this
series. So let's move from theoretical to practical: given this example,
why do you think out of tree LSMs are blocked?