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: <CAHC9VhQL_FkUH8F1fvFZmC-8UwZh3zkwjomCo1PiWNW0EGYUPw@mail.gmail.com>
Date: Tue, 13 May 2025 23:06:18 -0400
From: Paul Moore <paul@...l-moore.com>
To: KP Singh <kpsingh@...nel.org>
Cc: bboscaccy@...ux.microsoft.com, James.Bottomley@...senpartnership.com, 
	bpf@...r.kernel.org, code@...icks.com, corbet@....net, davem@...emloft.net, 
	dhowells@...hat.com, gnoack@...gle.com, herbert@...dor.apana.org.au, 
	jarkko@...nel.org, jmorris@...ei.org, jstancek@...hat.com, 
	justinstitt@...gle.com, keyrings@...r.kernel.org, 
	linux-crypto@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, linux-security-module@...r.kernel.org, 
	llvm@...ts.linux.dev, masahiroy@...nel.org, mic@...ikod.net, morbo@...gle.com, 
	nathan@...nel.org, neal@...pa.dev, nick.desaulniers+lkml@...il.com, 
	nicolas@...sle.eu, nkapron@...gle.com, roberto.sassu@...wei.com, 
	serge@...lyn.com, shuah@...nel.org, teknoraver@...a.com, 
	xiyou.wangcong@...il.com, kysrinivasan@...il.com
Subject: Re: [PATCH v3 0/4] Introducing Hornet LSM

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, I'm
expecting that the BPF kernel code would want to adopt an "allow all"
policy when it comes to authorizing signed and unsigned BPF programs,
delegating any additional restrictions to the LSM.  With that in mind
I think we need to agree on a way for the BPF verifier to indicate
that it has verified the signature is correct to the LSM, and we need
a new LSM hook which runs *after* the verifier so that it can inspect
the results of the signature verification.  While it might be tempting
to relocate the existing security_bpf_prog_load() hook, I believe it
makes sense to leave that hook before the verifier for those LSMs that
wish control access prior to the verifier's inspection using criteria
other than signatures.

With respect to the LSM hook, since it appears that the signature is
going to be included in the bpf_attr struct, and I'm *guessing* the
best way for the verifier to indicate the result of the signature
verification is via a field inside bpf_prog_aux, this means the hook
could look something like this:

  int security_bpf_prog_verified(bpf_prog, bpf_attr);

... and be called immediately after bpf_check() in bpf_prog_load().
As far as the new field in bpf_prog_aux is concerned, I think we can
probably start off with a simple bool to indicate whether a signature
was verified or not, with an understanding that we can move to a
richer construct in the future if we find it necessary.  Neither of
these are directly visible to userspace so we have the ability to
start simple and modify as needed.

Does this sound reasonable to everyone?  Does anyone have any other
thoughts on the authorization aspect of BPF signature verification?

-- 
paul-moore.com