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: <CAADnVQJ4GDKvLSWuAMdwajA0V2DEw5m-O228QknW8Eo9jxhyig@mail.gmail.com>
Date: Fri, 16 May 2025 16:49:09 -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 Fri, May 16, 2025 at 12:49 PM Paul Moore <paul@...l-moore.com> wrote:
>
> On Wed, May 14, 2025 at 2:48 PM KP Singh <kpsingh@...nel.org> wrote:
> > On Wed, May 14, 2025 at 5:06 AM Paul Moore <paul@...l-moore.com> wrote:
> > > On Sat, May 10, 2025 at 10:01 PM KP Singh <kpsingh@...nel.org> wrote:
> > > >
> > >
> > > ...
> > >
> > > > The signature check in the verifier (during BPF_PROG_LOAD):
> > > >
> > > >     verify_pkcs7_signature(prog->aux->sha, sizeof(prog->aux->sha),
> > > > sig_from_bpf_attr, …);
> > >
> > > I think we still need to clarify the authorization aspect of your
> > > proposed design.
> > >
> > > Working under the assumption that the core BPF kernel code doesn't
> > > want to enforce any restrictions, or at least as few as possible ...
> >
> > The assumption is not true, I should have clarified it in the original
> > design. With the UAPI / bpf_attr the bpf syscall is simply denied if
> > the signature does not verify, so we don't need any LSM logic for
> > this. There is really no point in continuing as signature verification
> > is a part of the API contract when the user passes the sig, keyring in
> > the bpf syscall.
>
> 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.

> * 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, but it probably should be
a job of trivial LSM:
if (prog_attr doesn't have signature &&
   (task == .. || task is under certain cgroup || whatever))
  disallow.


Note that the prog verification itself is independent of the signature.
If prog fails to pass safety checks it will still be rejected
even if signature is ok.
We're not going to do a verifier bypass.