linux-kernel - Re: [PATCH v3 0/4] Introducing Hornet LSM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAADnVQ+wE5cGhy6tgmWgUwkNutueEsrhh6UR8N2fzrZjt-vb4g@mail.gmail.com>
Date: Sat, 17 May 2025 09:13:38 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Paul Moore <paul@...l-moore.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 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.

> > but it probably should be a job of trivial LSM ...
>
> Exactly.  If the LSM is simply verifying the signature validation
> state of the BPF program being loaded it seems like an addition to IPE
> would be the best option from an upstream, in-tree perspective.
> However, with the post verifier LSM hook in place, one could also
> supply a BPF LSM to do something similar.
>
> It sounds like we are in agreement on the desirability and need for a
> post verifier LSM hook; we'll keep moving forward with this idea
> despite KP's earlier objections to the hook.

Don't twist my words please.
We're absolutely _not_ in agreement.
What I described above can be done with the existing hook and
its current set of arguments.
We're not going to move or change the existing hook.