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

From: Paul Moore <paul@paul-moore.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	linux-security-module@vger.kernel.org,
	John Johansen <john.johansen@canonical.com>,
	Kees Cook <kees@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH 04/10] CaitSith: Add header file.
Date: Wed, 9 Nov 2022 09:48:43 -0500	[thread overview]
Message-ID: <CAHC9VhS=0Ts8E647JJiJ6dwPmnuLuYTyOS0QEYJO_EmAb3yFcw@mail.gmail.com> (raw)
In-Reply-To: <f52e6e9f-5e95-8843-c2f5-c50bba48e5e4@I-love.SAKURA.ne.jp>

On Wed, Nov 9, 2022 at 5:14 AM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
> On 2022/11/09 11:20, Paul Moore wrote:
> > On Tue, Nov 8, 2022 at 5:20 AM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >> What I'm asking you are that:
> >>
> >>   Please don't lock out out-of-tree LSM modules (by requiring an LSM id integer value
> >>   which are assigned to only in-tree LSM modules) because we can't accept whatever LSM
> >>   modules as in-tree.
> >>
> >>   Please don't lock out loadable LSM modules (by using fixed sized array) because
> >>   locking out loadable LSM modules reduces the value of your LSM stacking work.
> >>
> >> Quite simple.
> >
> > Tetsuo, at this point I think we all understand your concern and I
> > appreciate and respect the passion you have for your argument.
> > However, I think the rest of the developers, including myself, have
> > also made our points very clear.  While there may still be revisions
> > to the syscall patches, I believe identifying LSMs via a token value
> > as opposed to a string value is the better option for the upstream
> > Linux Kernel.
>
> I'm not opposing to identifying LSMs via a token value. I'm opposing to who can
> obtain a token value, for I haven't heard a clear promise that we shall allow
> whatever LSM modules to obtain a token value.

In that case, let me be very clear on this issue: at this point in
time I will not merge patches which assign LSM ID tokens in the
upstream Linux Kernel to out-of-tree LSMs.  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.

> > Thank you for your comments, but I'm considering this settled.
> >
>
> Never settled, unless you all promise that we shall assign a token value to whatever
> LSM modules (regardless of whether that LSM module is already in-tree or not).

As the person who ultimately is responsible for supporting,
maintaining, and merging LSM related patches into the upstream Linux
Kernel I am considering this issue settled until there is some other
significant change that warrants reconsideration of the policy
mentioned above.  Of course you are welcome to disagree, and you can
continue to voice your objections if you like, but the issue is
settled in my mind.

-- 
paul-moore.com