Message-ID: <CAHC9VhQ7Rr1jJm=HY2ixUWpsRuwCxjOq5OTMfn5k5hRzxTCz-Q@mail.gmail.com>
Date: Mon, 19 May 2025 18:58:53 -0400
From: Paul Moore <paul@...l-moore.com>
To: KP Singh <kpsingh@...nel.org>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>, 
	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 Mon, May 19, 2025 at 6:20 PM KP Singh <kpsingh@...nel.org> wrote:
> On Sun, May 18, 2025 at 11:34 PM Paul Moore <paul@...l-moore.com> wrote:
> > 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.
>
> Neither the aux field, nor the hook are required because:
>
> * If the signature is passed, it will be enforced, there are no
> "runtime aspects" that need to be configurable here.
> * What the LSM can specify a policy for is when a signature is not
> passed, for this, it does not need an aux field or a signature or the
> new hook, existing hooks are sufficient.

When the kernel performs a security relevant operation, such as
verifying the signature on a BPF program, where the result of the
operation serves as input to a policy decision, system measurement,
audit event, etc. the LSM hook needs to be located after the security
relevant operation takes place so that the hook is able to properly
take into account the state of the event/system and record the actual
result as opposed to an implied result (this is critical for auditing,
measurement, attestation, etc.).

You explained why you believe the field/hook is not required, but I'm
asking for your *technical*objections*.  I understand that you believe
these changes are not required, but as described above, I happen to
disagree and therefore it would be helpful to understand the technical
reasons why you can't accept the field/hook changes.  Is there a
technical reason which would prevent such changes, or is it simply a
rejection of the use case and requirements above?

-- 
paul-moore.com

Powered by blists - more mailing lists