Re: [RFC][PATCH 3/4] lsm: Redefine LSM_HOOK() macro to add return value flags as argument

From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Paul Moore <paul@paul-moore.com>
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
	martin.lau@linux.dev, song@kernel.org, yhs@fb.com,
	john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
	haoluo@google.com, jolsa@kernel.org, revest@chromium.org,
	jackmanb@chromium.org, jmorris@namei.org, serge@hallyn.com,
	bpf@vger.kernel.org, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Roberto Sassu <roberto.sassu@huawei.com>,
	stable@vger.kernel.org
Subject: Re: [RFC][PATCH 3/4] lsm: Redefine LSM_HOOK() macro to add return value flags as argument
Date: Wed, 16 Nov 2022 09:11:15 +0100	[thread overview]
Message-ID: <83cbff40f16a46e733a877d499b904cdf06949b6.camel@huaweicloud.com> (raw)
In-Reply-To: <CAHC9VhTA7SgFnTFGNxOGW38WSkWu7GSizBmNz=TuazUR4R_jUg@mail.gmail.com>

On Tue, 2022-11-15 at 21:27 -0500, Paul Moore wrote:
> On Tue, Nov 15, 2022 at 12:58 PM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
> > From: Roberto Sassu <roberto.sassu@huawei.com>
> > 
> > Define four return value flags (LSM_RET_NEG, LSM_RET_ZERO, LSM_RET_ONE,
> > LSM_RET_GT_ONE), one for each interval of interest (< 0, = 0, = 1, > 1).
> > 
> > Redefine the LSM_HOOK() macro to add return value flags as argument, and
> > set the correct flags for each LSM hook.
> > 
> > Implementors of new LSM hooks should do the same as well.
> > 
> > Cc: stable@vger.kernel.org # 5.7.x
> > Fixes: 9d3fdea789c8 ("bpf: lsm: Provide attachment points for BPF LSM programs")
> > Signed-off-by: Roberto Sassu <roberto.sassu@huawei.com>
> > ---
> >  include/linux/bpf_lsm.h       |   2 +-
> >  include/linux/lsm_hook_defs.h | 779 ++++++++++++++++++++--------------
> >  include/linux/lsm_hooks.h     |   9 +-
> >  kernel/bpf/bpf_lsm.c          |   5 +-
> >  security/bpf/hooks.c          |   2 +-
> >  security/security.c           |   4 +-
> >  6 files changed, 466 insertions(+), 335 deletions(-)
> 
> Just a quick note here that even if we wanted to do something like
> this, it is absolutely not -stable kernel material.  No way.

I was unsure about that. We need a proper fix for this issue that needs
to be backported to some kernels. I saw this more like a dependency.
But I agree with you that it would be unlikely that this patch is
applied to stable kernels.

For stable kernels, what it would be the proper way? We still need to
maintain an allow list of functions that allow a positive return value,
at least. Should it be in the eBPF code only?

Thanks

Roberto