linux-kernel - Re: [RFC PATCH security-next 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] [day] [month] [year] [list]

Message-ID: <Z98u8BAMJKqUiojn@kernel.org>
Date: Sat, 22 Mar 2025 23:43:12 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Paul Moore <paul@...l-moore.com>
Cc: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>,
	Jonathan Corbet <corbet@....net>,
	David Howells <dhowells@...hat.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	"David S. Miller" <davem@...emloft.net>,
	James Morris <jmorris@...ei.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Masahiro Yamada <masahiroy@...nel.org>,
	Nathan Chancellor <nathan@...nel.org>,
	Nicolas Schier <nicolas@...sle.eu>, Shuah Khan <shuah@...nel.org>,
	Mickaël Salaün <mic@...ikod.net>,
	Günther Noack <gnoack@...gle.com>,
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Jan Stancek <jstancek@...hat.com>, Neal Gompa <neal@...pa.dev>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-kbuild@...r.kernel.org,
	linux-kselftest@...r.kernel.org, bpf@...r.kernel.org,
	llvm@...ts.linux.dev, nkapron@...gle.com, teknoraver@...a.com,
	roberto.sassu@...wei.com, xiyou.wangcong@...il.com
Subject: Re: [RFC PATCH security-next 0/4] Introducing Hornet LSM

On Sat, Mar 22, 2025 at 04:48:14PM -0400, Paul Moore wrote:
> On Sat, Mar 22, 2025 at 4:44 PM Paul Moore <paul@...l-moore.com> wrote:
> >
> > On Sat, Mar 22, 2025 at 1:22 PM Jarkko Sakkinen <jarkko@...nel.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 :)
> >
> > 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.
> >
> > 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.
> 
> Forgive me, I mixed up my "A" and "B" above :/
> 
> > 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.
> 
> ... and I did again here
> 
> > 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.
> 
> ... and once more here because why not? :)

No worries I was able to decipher this :-)

> 
> > 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 ;)
> 
> -- 
> paul-moore.com

BR, Jarkko