Re: [GIT PULL] tomoyo update for v6.12

From: Paul Moore
Date: Tue Oct 01 2024 - 10:01:56 EST


On Sat, Sep 28, 2024 at 9:55 AM Jonathan Corbet <corbet@xxxxxxx> wrote:
> Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> writes:
> > The following changes since commit ada1986d07976d60bed5017aa38b7f7cf27883f7:
> >
> > tomoyo: fallback to realpath if symlink's pathname does not exist (2024-09-25 22:30:59 +0900)
> >
> > are available in the Git repository at:
> >
> > git://git.code.sf.net/p/tomoyo/tomoyo.git tags/tomoyo-pr-20240927
> >
> > for you to fetch changes up to ada1986d07976d60bed5017aa38b7f7cf27883f7:
> >
> > tomoyo: fallback to realpath if symlink's pathname does not exist (2024-09-25 22:30:59 +0900)
> > ----------------------------------------------------------------
> > One bugfix patch, one preparation patch, and one conversion patch.
>
> [...]
>
> > I was delivering pure LKM version of TOMOYO (named AKARI) to users who
> > cannot afford rebuilding their distro kernels with TOMOYO enabled. But
> > since the LSM framework was converted to static calls, it became more
> > difficult to deliver AKARI to such users. Therefore, I decided to update
> > TOMOYO so that people can use mostly LKM version of TOMOYO with minimal
> > burden for both distributors and users.
>
> I must confess that this change confuses me a bit. Loadable LSM modules
> have been out of the picture for a long time, has that changed now?
>
> Even stranger, to me at least, is the backdoor symbol-export mechanism.
> That seems like ... not the way we do things. Was the need for this so
> urgent that you couldn't try to get those symbols exported properly?

[ASIDE: Thanks for the heads-up Jon, I've also CC'd the LSM list as I
think this pull request is a surprise to all of us.]

I'm confused, or rather surprised to see this patchset/PR, and even
more surprised to see it has landed in Linus' tree. While I suppose
we don't explicitly state that LSMs should CC their pull-requests to
the LSM list, there is definitely convention and plenty of history
here. Even Tetsuo has previously CC'd the TOMOYO pull requests to the
LSM list (below). Considering the history of TOMOYO pull requests,
LSM conventions, and the contents of the pull request, I can't help
but think the omission here was done with deliberate intent. I'm also
surprised it was posted, and pulled, roughly two days from the end of
the merge window.

https://lore.kernel.org/linux-security-module/?q=%22%5BGIT+PULL%5D%22+f%3Apenguin-kernel%40i-love.sakura.ne.jp

Unfortunately this pull request was sent while I was traveling and not
in a good position to respond, or even properly notice it; as things
are I'm typing this email from the seat of a plane (the first time
I've had network access on a laptop since Thursday morning). If I had
seen this last week I would have voiced an objection that this pull
request effectively duplicates the LSM framework hooks in TOMOYO (and
likely a few other things, I'm only quickly scanning the patches ...);
I wouldn't have accepted something like this in a new LSM submission
and I can only see this as a bad faith move on the part of Tetsuo.

Linus, it's unclear if you're still following this thread after the
pull, but can you provide a little insight on your thoughts here? I
don't want to go down the "security people are insane" discussion
hole, but I'd would like to know where the line is drawn with
accepting changes like this: are you consciously supportive of
individual LSMs sidestepping the LSM framework like this when they are
not able to gain approval from the LSM maintainer and the LSM
community as a whole?

--
paul-moore.com