Message-ID: <CAHC9VhQq0-D=p9Kicx2UsDrK2NJQDyn9psL-PWojAA+Y17WiFQ@mail.gmail.com>
Date: Mon, 16 Sep 2024 04:08:11 -0400
From: Paul Moore <paul@...l-moore.com>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, linux-security-module@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] lsm/lsm-pr-20240911

On Sun, Sep 15, 2024 at 8:38 PM Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
> On 2024/09/14 0:28, Paul Moore wrote:
> > I find it somewhat amusing that you are complaining about the LSM
> > framework not accepting new LSMs in the same pull request where we are
> > adding a new LSM (IPE).  As a reminder, we have documented guidelines
> > regarding the addition of new LSMs:
> >
> > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md
> (...snipped...)
> > While I have no intention to negatively impact out-of-tree LSMs,
>
> What I call "patent examination" is "New LSM Guidelines" section within
> that link. That section includes "here are a list of requirements for
> new LSM submissions:" and "The new LSM must be sufficiently unique", and
> out-of-tree LSMs which cannot satisfy it won't be able to become in-tree.
> If we apply this requirement to userspace program, this requirement means
> you are declaring that "postfix" (or anything except "sendmail") cannot
> become in-tree because "sendmail" is already in-tree. This is a clear
> intention of negatively impact out-of-tree LSMs. People have the right to
> use whatever subsets/alternatives. Even if a new LSM has were completely a
> subset of existing in-tree LSMs, people have the right to use such LSM.

Comparing userspace applications to kernel code isn't a fair
comparison as a userspace application can generally be added without
impacting the other applications on the system.

> While I consider that some of out-of-tree LSMs being unable to become in-tree
> is inevitable, the requirement that any LSM has to be built-in is a barrier
> for LSMs which cannot be built-in.

Anyone is always free to build their own kernel with whatever code
changes they like, this is the beauty of the kernel source being
available and licensed as Open Source.  You are free to build a kernel
with whatever LSM you like included and enabled.  You have been shown
examples on how to do this in previous threads.

> People have the right to install whatever userspace software / kernel modules
> they need.

Anyone is free to build their own kernel with whatever LSMs they want,
either in-tree or out-of-tree; the static call changes do not prevent
that.

> > My focus is on the upstream Linux kernel and ensuring that the upstream,
> > in-tree LSMs have the best framework possible to ensure their proper
> > operation and ease of development/maintenance.  While I have no
> > intention to negatively impact out-of-tree LSMs, I will not harm the
> > upstream code base solely to support out-of-tree LSMs.  Further, if
> > improvements to the upstream LSM framework are determined to harm
> > out-of-tree LSMs, that shall be no reason to reject the upstream
> > improvements.
>
> I have been asking you for a solution for "in-tree but not built-in" LSM
> (namely TOMOYO). You are refusing to provide a solution for the sake of
> "in-tree and built-in" LSMs. The "static call" changes fails to ensure that
> the upstream, in-tree TOMOYO to have the best framework. The "static call"
> changes makes the upstream, in-tree TOMOYO to have a worse framework than
> now.

As mentioned so many times before, the "in-tree but not built-in" LSM
problem is entirely a distribution/binary-kernel problem.  The
upstream kernel community is not responsible for the choices and
individual build configurations of the different Linux distros.
Support for mechanisms which allow for dynamic LSMs in pre-built
distro kernels is something we could consider, but so far everything
that has been proposed has had a negative impact on the upstream
kernel sources and has been rejected as a result.

-- 
paul-moore.com

Powered by blists - more mailing lists