[PATCH v3 0/4] Introducing Hornet LSM

[James Bottomley]

On Mon, 2025-05-05 at 22:41 +0200, KP Singh wrote:
> On Mon, May 5, 2025 at 7:30 PM Blaise Boscaccy
> <bboscaccy at linux.microsoft.com> wrote:
> > 
> > KP Singh <kpsingh at kernel.org> writes:
> > 
> > [...]
> > 
> > > Now if you really care about the use-case and want to work with
> > > the maintainers and implement signing for the community, here's
> > > how we think it should be done:
> > > 
> > > * The core signing logic and the tooling stays in BPF, something
> > > that the users are already using. No new tooling.
> > > * The policy decision on the effect of signing can be built into
> > > various existing LSMs. I don't think we need a new LSM for it.
> > > * A simple UAPI (emphasis on UAPI!) change to union bpf_attr in
> > > uapi/bpf.h in the BPF_PROG_LOAD command:
> > > 
> > > __aligned_u64 signature;
> > > __u32 signature_size;
> > 
> > I think having some actual details on the various parties'
> > requirements here would be helpful. KP, I do look forward to seeing
> > your design; however, having code signing proposals where the
> > capabilities are dictated from above and any dissent is dismissed
> > as "you're doing it wrong" isn't going to be helpful to anyone that
> > needs to use this in practice.
> 
> Please don't misrepresent the facts, you got feedback from Alexei in
> various threads, but you chose to argue on the points that were
> convenient for you (i.e. usage of BPF internal APIs) and yet you
> claim to "work with the BPF community and maintainers" by arguing
> instead of collaborating and paying attention to the feedback given
> to you.

I'm with Paul on this: if you could share your design ideas more fully
than you have above that would help make this debate way more
technical.

However, I will try to respond to the other technical points from a
general security point of view if it helps but I've made some guesses
about what will work for you.

[...]
> 2. Alexei suggested to you in
> https://lore.kernel.org/bpf/87plhhjwqy.fsf@microsoft.com/
> 
>   "A signature for the map plus a signature for the prog
>   that is tied to a map might be a better option.
>   At map creation time the contents can be checked,
>   the map is frozen, and then the verifier can proceed
>   with prog's signature checking."
> 
> You never replied to this.

>From a general security perspective allowing the creation of signed
objects that must be combined in order to produce a thing (be it a
program, a policy or whatever) is always problematic because after
you've produced a range of these objects signed with the same key, they
can be mixed and matched by an attacker, in ways you didn't anticipate,
to produce unintended results and possibly exploits.  To avoid this, a
single signature must cover the entire combination.

Having a single signature doesn't mean you can't make your scheme work:
the signature could be over an array of two hashes, one for the program
and one for the map, meaning that the signature could be verified and
the hashes extracted, which could then be verified at different points
in the execution and verification flow: say verify the program hash
immediately but do the map hash after you're sure it can't be modified.

> 3. To signing the attachment points, you replied
> 
> > That statement is quite questionable. Yes, IIRC you brought that
> > up. And again, runtime policy enforcement has nothing to do with
> > proving code provenance. They are completely independent concerns.
> 
> The place where the BPF program is attached is a key part of the
> provenance of the BPF program and its security (and other) effects
> can vary greatly based on that. (e.g. imagine a reject all LSM
> program that is attached to the wrong LSM hook). This is why it's not
> the same as module loading.

I don't believe anyone's disputing this.  However, there is a
difference between provenance and policy.  Signatures are just about
provenance. You proposed adding a policy language to signing at LPC in
2022 and I believe this could be done incrementally to the current
patch set.

One possible stepping stone to this is to add signatures now and policy
later but if you want the attach point also covered now, how about
adding an optional third hash over attach_btf_id and the fd; if the
hash is present it binds the attach point and if it isn't the skeleton
can attach arbitrarily? 

> 4.
> https://lore.kernel.org/bpf/CAADnVQKF+B_YYwOCFsPBbrTBGKe4b22WVJFb8C0PHGmRAjbusQ@mail.gmail.com/
> 
> Programs can still access maps, now if you combine the issue of
> ELF-less loaders and that maps are writeable from other programs as
> freezing only affects userspace (i.e. when a binary gets an FD to a
> map and tries to modify it with syscalls) your implementation fails.

In a world of trusted BPF, I think you can get to some confidence that
an attacker can't simply insert an arbitrary BPF program to do this and
nor could they get into ring0 without compromising the kernel, so map
freezing provides a reasonable measure of safety.  It's not perfect,
but it's good enough.

> The reply there about trusted user-space still needs to come with
> better guarantees from the kernel, and the kernel can indeed give
> better guarantees, which we will share. The reason for this is that
> your trusted binary is not immune to attacks, and once an attacker
> gains code execution as this trusted binary, there is no containing
> the compromise.

This is whitelisting systemd again?  I think as a temporary measure
until systemd gets on-board with BPF signing, a config parameter is not
unreasonable.

I also get the impression that there might be a disagreement over
scope: what seems to be coming out of BPF is that every signing problem
and scenario must be solved before signing can be considered
acceptable; however, I think it's not unreasonable to attempt to cover
a portion of the use cases and allow for future additions of things
like policy so we can get some forward motion to allow others to play
with it and produce patches based on their use cases.

Regards,

James