lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHC9VhRnTrjP3kNXMmzsK4oZL7WD+uH0OuXszEPgTc5YoT5dew@mail.gmail.com>
Date: Tue, 1 Oct 2024 10:00:17 -0400
From: Paul Moore <paul@...l-moore.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>, Jonathan Corbet <corbet@....net>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>, LKML <linux-kernel@...r.kernel.org>, 
	linux-security-module@...r.kernel.org
Subject: Re: [GIT PULL] tomoyo update for v6.12

On Sat, Sep 28, 2024 at 9:55 AM Jonathan Corbet <corbet@....net> wrote:
> Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ