Re: [RFC PATCH security-next 0/4] Introducing Hornet LSM

[Jarkko Sakkinen <jarkko@kernel.org>]

On Sat, Mar 22, 2025 at 04:44:13PM -0400, Paul Moore wrote:
> On Sat, Mar 22, 2025 at 1:22 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > On Fri, Mar 21, 2025 at 09:45:02AM -0700, Blaise Boscaccy wrote:
> > > This patch series introduces the Hornet LSM.
> > >
> > > Hornet takes a simple approach to light-skeleton-based eBPF signature
> >
> > Can you define "light-skeleton-based" before using the term.
> >
> > This is the first time in my life when I hear about it.
> 
> I was in the same situation a few months ago when I first heard about it :)
> 
> Blaise can surely provide a much better answer that what I'm about to
> write, but since Blaise is going to be at LSFMMBPF this coming week I
> suspect he might not have a lot of time to respond to email in the
> next few days so I thought I would do my best to try and answer :)

Yeah, I don't think there is anything largely wrong in the feature
itself but it speaks language that would fit to eBPF subsystem list,
not here :-)

I.e. assume only very basic knowledge of eBPF and explain what stuff
mentioned actually does. Like bpftool statement should be opened up
fully.

> 
> An eBPF "light skeleton" is basically a BPF loader program and while
> I'm sure there are several uses for a light skeleton, or lskel for
> brevity, the single use case that we are interested in here, and the
> one that Hornet deals with, is the idea of using a lskel to enable
> signature verification of BPF programs as it seems to be the one way
> that has been deemed acceptable by the BPF maintainers.

I got some grip but the term only should be used IMHO in the commit
message, if it is defined at first :-)

> 
> Once again, skipping over a lot of details, the basic idea is that you
> take your original BPF program (A), feed it into a BPF userspace tool
> to encapsulate the original program A into a BPF map and generate a
> corresponding light skeleton BPF program (B), and then finally sign
> the resulting binary containing the lskel program (B) and map
> corresponding to the original program A.  At runtime, the lskel binary
> is loaded into the kernel, and if Hornet is enabled, the signature of
> both the lskel program A and original program B is verified.  If the
> signature verification passes, lskel program A performs the necessary
> BPF CO-RE transforms on BPF program A stored in the BPF map and then
> attempts to load the original BPF program B, all from within the
> kernel, and with the map frozen to prevent tampering from userspace.

When you speak about corresponding lskel program what does that
program contain? Is it some kind of new version of the same
program with modifications, or?

I neither did not know what BPF CO-RE is but I googled it ;-)

> 
> Hopefully that helps fill in some gaps until someone more
> knowledgeable can provide a better answer and/or correct any mistakes
> in my explanation above ;)

Sure... Thanks for the explanations!

> 
> -- 
> paul-moore.com

BR, Jarkko