Message-ID: <CAHC9VhRz4T+Ad6z1u+b+XJoXi7eORax-5KuAbH=O5BOTQAhA7w@mail.gmail.com>
Date: Fri, 13 Sep 2024 11:28:44 -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 Fri, Sep 13, 2024 at 8:28 AM Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
> On 2024/09/13 10:29, Paul Moore wrote:
> > Linus,
> >
> > We've got a reasonably large pull request for the LSM framework this
> > time (at least it's large for us), here are the highlights:
> >
> > * Move the LSM framework to static calls
> >
> > Based on some of our exchanges over the summer, it sounds like you
> > are already familiar with the effort to convert the LSM callbacks
> > from function pointers to static calls.  This pull request includes
> > that work and transitions the vast majority of the LSM callbacks into
> > static calls.  Those callbacks which haven't been converted were
> > left as-is due to the general ugliness of the changes required to
> > support the static call conversion; we can revisit those callbacks
> > at a future date.
> >
> > It is worth mentioning that Tetsuo Handa is opposed to the static call
> > patches, some even carry his NACK, as they make it more difficult to
> > dynamically load out-of-tree LSMs, or unsupported LSMs on distro kernels.
> > Many of us have tried to explain that out-of-tree LSMs are not a
> > concern for the upstream LSM framework, or the Linux kernel in general,
> > and that decisions around what LSMs are enabled in distro kernels is
> > a distro issue, not an upstream issue, but unfortunately Tetsuo
> > continues to disregard these arguments.
>
> No, this is not only a distro issue but also an upstream issue!
> Because the upstream cannot afford accepting whatever proposed LSMs
> ( https://lkml.kernel.org/r/8ac2731c-a1db-df7b-3690-dac2b371e431@I-love.SAKURA.ne.jp ).

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

... these guidelines were discussed quite a bit on-list some time ago,
and are essentially the same undocumented guidelines the LSM framework
has been following for quite some time now (I will admit the doc and
testing bullet points are likely new).

[SIDE NOTE: Eventually this doc will move over into the kernel tree,
but I still consider it too much of a work-in-progress/draft to merge
into mainline.  We probably also need to do a bit of tidying up in the
kernel doc area relating to LSMs.]

> That is, out-of-tree LSMs cannot become in-tree and obtain stable LSM ID ...

We've discussed this many times before, obtaining stable magic numbers
(e.g. syscall numbers, LSM IDs, etc.) isn't possible until the
associated code appears in a tagged released from Linus' tree.  Of
course there are workarounds which we've discussed, and Kees even put
together a toy LSM demonstrating these workarounds.

You've heard my stance on this several times in the past, but I'll
repeat myself one more time for the sake of the wider audience.  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 believe this policy is not only consistent with that
of previous LSM maintainers, but of the general Linux kernel as well.

-- 
paul-moore.com

Powered by blists - more mailing lists