Message-ID: <CAC1LvL2F_WbObrdcumVZCKc7yLeq4e9PQhYHrLiyVzpzf=V_Xg@mail.gmail.com>
Date: Mon, 19 May 2025 16:00:56 -0700
From: Zvi Effron <zeffron@...tgames.com>
To: KP Singh <kpsingh@...nel.org>
Cc: Paul Moore <paul@...l-moore.com>, 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 3: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.
>

What about wanting to create a policy that requires signatures under certain
situations and allowing the lack of a signature under others? How is that
implemented with the existing hooks?
As I understand it, all the existing hooks know (would know) is that _if_ there
is a signature _then_ it will be enforced. There is no way to know _whether_
there is a signature.

An example policy I can think of is that most users (with CAP_BPF) must submit
signed programs but some users are exempted. Would that policy be able to be
made with the current hooks?

> - KP
>
> >
> > --
> > paul-moore.com
>

Powered by blists - more mailing lists