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: <CAHC9VhTeFBhdagvw4cT3EvA72EYCfAn6ToptpE9PWipG9YLrFw@mail.gmail.com>
Date: Fri, 16 May 2025 15:49:16 -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, 
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v3 0/4] Introducing Hornet LSM

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?

* 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?

-- 
paul-moore.com