On Sat, Mar 30, 2024 at 10:46 AM Dr. Greg [off-list ref] wrote:

On Thu, Mar 28, 2024 at 08:26:11PM -0400, Paul Moore wrote:

quoted

On Thu, Mar 28, 2024 at 11:38???AM Dr. Greg [off-list ref] wrote:

quoted

BPF provides an implementation and would be affected ...

quoted

Casey pretty much summed up my thoughts fairly well, including the
"Bear poking trimmed" comment, which was worth a good laugh :)

Very good, we will take Casey's e-mail as the official position of the
Linux security maintainers on the functionality under discussion and
similar issues moving forward.

You're welcome to take whatever lessons you want from this thread,
that is your choice, but please understand that your interpretation of
this thread may not accurately reflect the opinions or policies,
either now or in the future, of the subsystem maintainers.  I
understand that developers/engineers like hard rules, it's reassuring
and comforting; I'm right there with you.  Unfortunately, the Linux
kernel is a bizarrely complex beast with changes happening on a
regular basis and in an often unpredictable way.  While I do attempt
to provide guidelines on certain things, e.g. new LSMs, new LSM hooks,
etc., ultimately decisions still boil down to the
wonderfully/frustratingly vague "maintainer's discretion".

In this thread, especially the last few messages, the only "position"
I would suggest one take as a lesson, is that the LSM developers don't
need to be told about the BPF LSM, or BPF in general, because we have
all be struggling (?) with the challenges it brings for many, many
years already.  That isn't to say the BPF LSM, or eBPF in general, is
a bad technology - you can definitely do some cool things with it -
but integrating it into the kernel, and determining the appropriate
boundaries between BPF code and the kernel internals, has been (and
continues to be) a struggle.  Simply dig through the archives and
you'll see more than a few threads on this subject.

-- 
paul-moore.com