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: <CACYkzJ4+=3owK+ELD9Nw7Rrm-UajxXEw8kVtOTJJ+SNAXpsOpw@mail.gmail.com>
Date: Wed, 14 May 2025 20:48:23 +0200
From: KP Singh <kpsingh@...nel.org>
To: Paul Moore <paul@...l-moore.com>
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, 
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v3 0/4] Introducing Hornet LSM

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, I'm

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.

Also, since we have a solid grasp on the design and its implementation
being contained, it will be much simpler for us to actually implement
the patches. We will keep you posted.

- KP

> 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