Message-ID: <CAHC9VhRKZdEia0XUMs2+hRVC7oDzkBfkk5FPMD+Fq5V7mAk=Vg@mail.gmail.com>
Date: Sun, 18 May 2025 17:34:04 -0400
From: Paul Moore <paul@...l-moore.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: KP Singh <kpsingh@...nel.org>, Blaise Boscaccy <bboscaccy@...ux.microsoft.com>, 
	James Bottomley <James.Bottomley@...senpartnership.com>, bpf <bpf@...r.kernel.org>, 
	code@...icks.com, Jonathan Corbet <corbet@....net>, "David S. Miller" <davem@...emloft.net>, 
	David Howells <dhowells@...hat.com>, Günther Noack <gnoack@...gle.com>, 
	Herbert Xu <herbert@...dor.apana.org.au>, Jarkko Sakkinen <jarkko@...nel.org>, 
	James Morris <jmorris@...ei.org>, Jan Stancek <jstancek@...hat.com>, 
	Justin Stitt <justinstitt@...gle.com>, keyrings@...r.kernel.org, 
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, 
	"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>, 
	Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	"open list:KERNEL SELFTEST FRAMEWORK" <linux-kselftest@...r.kernel.org>, 
	LSM List <linux-security-module@...r.kernel.org>, 
	clang-built-linux <llvm@...ts.linux.dev>, Masahiro Yamada <masahiroy@...nel.org>, 
	Mickaël Salaün <mic@...ikod.net>, 
	Bill Wendling <morbo@...gle.com>, Nathan Chancellor <nathan@...nel.org>, Neal Gompa <neal@...pa.dev>, 
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>, Nicolas Schier <nicolas@...sle.eu>, nkapron@...gle.com, 
	Roberto Sassu <roberto.sassu@...wei.com>, "Serge E . Hallyn" <serge@...lyn.com>, 
	Shuah Khan <shuah@...nel.org>, Matteo Croce <teknoraver@...a.com>, 
	Cong Wang <xiyou.wangcong@...il.com>, kysrinivasan@...il.com, 
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v3 0/4] Introducing Hornet LSM

On Sun, May 18, 2025 at 11:52 AM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
> On Sat, May 17, 2025 at 10:49 PM Paul Moore <paul@...l-moore.com> wrote:
> > On May 17, 2025 12:13:50 PM Alexei Starovoitov
> > <alexei.starovoitov@...il.com> wrote:
> > > On Sat, May 17, 2025 at 8:03 AM Paul Moore <paul@...l-moore.com> wrote:
> > >> On Fri, May 16, 2025 at 7:49 PM Alexei Starovoitov
> > >> <alexei.starovoitov@...il.com> wrote:
> > >>> On Fri, May 16, 2025 at 12:49 PM Paul Moore <paul@...l-moore.com> wrote:
> > >>>>
> > >>>> I think we need some clarification on a few of these details, it would
> > >>>> be good if you could answer the questions below about the
> > >>>> authorization aspects of your design?
> > >>>>
> > >>>> * Is the signature validation code in the BPF verifier *always* going
> > >>>> to be enforced when a signature is passed in from userspace?  In other
> > >>>> words, in your design is there going to be either a kernel build time
> > >>>> or runtime configuration knob that could selectively enable (or
> > >>>> disable) signature verification in the BPF verifier?
> > >>>
> > >>> If there is a signature in union bpf_attr and it's incorrect
> > >>> the prog_load command will be rejected.
> > >>> No point in adding a knob to control that.
> > >>
> > >> I agree that when a signature is provided and that signature check
> > >> fails, the BPF load should be rejected.  I'm simply trying to
> > >> understand how you envision your design handling all of the cases, not
> > >> just this one, as well as what build and runtime options you expect
> > >> for controlling various aspects of this behavior.
> > >>
> > >>>> * In the case where the signature validation code in the BPF verifier
> > >>>> is active, what happens when a signature is *not* passed in from
> > >>>> userspace?  Will the BPF verifier allow the program load to take
> > >>>> place?  Will the load operation be blocked?  Will the load operation
> > >>>> be subject to a more granular policy, and if so, how do you plan to
> > >>>> incorporate that policy decision into the BPF program load path?
> > >>>
> > >>> If there is no signature the existing loading semantics will remain intact.
> > >>> We can discuss whether to add a sysctl or cgroup knob to disallow
> > >>> loading when signature is not present ...
> > >>
> > >> As mentioned earlier this week, if the BPF verifier is performing the
> > >> signature verification as KP described, we will need a LSM hook after
> > >> the verifier to serve as an access control point.  Of course that
> > >> doesn't preclude the addition of some type of sysctl/cgroup/whatever
> > >> based access control, but the LSM hook would be needed regardless.
> > >
> > > No. New hook is not needed.
> >
> > It would be good for you to explain how the existing LSM hook is sufficient
> > to authorize the loading of a BPF program using the signature validation
> > state determined in the BPF verifier.
>
> I already explained:
> .. a job of trivial LSM:
> if (prog_attr doesn't have signature &&
>    (task == .. || task is under certain cgroup || whatever))
>   disallow.

I read that earlier reply as an example that covers a sample use case,
I didn't realize you were asserting that was the only approach you
were considering.  Perhaps that was the source of confusion earlier,
we may disagree, but I don't intentionally "twist" words; not only is
that rude, it's just stupid in public, archived discussions.

As I mentioned previously, we really need to see an explicit yes/no
flag from the BPF verifier to indicate that the signature on the BPF
program has been validated.  It really should be as simple as adding a
bool to bpf_prog_aux which the BPF verifier sets to true upon
successful signature validation, and then an LSM can use this flag as
input to an access control decision in a hook placed after the
verifier.  Are you objecting to the addition of a flag in the
bpf_prog_aux struct (or some other struct tightly coupled to the BPF
program), the LSM hook after the verifier, or both?  It would also be
helpful if you can elaborate on the technical reasons behind these
objections.

-- 
paul-moore.com

Powered by blists - more mailing lists