Re: [PATCH] Do not require attributes for security_inode_init_security.

From: Paul Moore <paul@paul-moore.com>
To: "Dr. Greg" <greg@enjellic.com>
Cc: linux-security-module@vger.kernel.org, roberto.sassu@huaweicloud.com
Subject: Re: [PATCH] Do not require attributes for security_inode_init_security.
Date: Sat, 30 Mar 2024 17:39:28 -0400	[thread overview]
Message-ID: <CAHC9VhRruSLET+aOhCt7WKucWNBE_qLCYV3won+p10XOjLLiHQ@mail.gmail.com> (raw)
In-Reply-To: <20240330144604.GA4625@wind.enjellic.com>

On Sat, Mar 30, 2024 at 10:46 AM Dr. Greg <greg@enjellic.com> wrote:
> On Thu, Mar 28, 2024 at 08:26:11PM -0400, Paul Moore wrote:
> > On Thu, Mar 28, 2024 at 11:38???AM Dr. Greg <greg@enjellic.com> wrote:
> > >
> > > BPF provides an implementation and would be affected ...
>
> > 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