linux-kernel - Re: [RFC 00/11] Reintroduce 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: <CAHtS32_TPrURNQkn+a1RrJRhUm7sPBWz37CPX81sG-LnYGuh5Q@mail.gmail.com>
Date: Thu, 18 Dec 2025 09:40:32 -0800
From: ryan foster <foster.ryan.r@...il.com>
To: Blaise Boscaccy <bboscaccy@...ux.microsoft.com>
Cc: James.Bottomley@...senpartnership.com, akpm@...ux-foundation.org, 
	bpf@...r.kernel.org, corbet@....net, dhowells@...hat.com, gnoack@...gle.com, 
	jmorris@...ei.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-security-module@...r.kernel.org, linux@...blig.org, mic@...ikod.net, 
	paul@...l-moore.com, serge@...lyn.com
Subject: Re: [RFC 00/11] Reintroduce Hornet LSM

Hi Paul, Blaise,

Thanks for clarifying, that matches my understanding.

My read is Hornet's semantic goal is load-time provenance and
integrity: validate the user-generated inputs once the kernel has
constructed the final in-kernel program instance (post-relocation,
with any integrity-relevant referenced inputs accounted for), and
record that result so LSM/policy can make decisions based on a fact
the kernel can truthfully assert.

Attaching and linking are separate runtime policy/capability
questions. It makes sense that SELinux, IPE, or a BPF LSM program
could choose to gate attach/link based on whether Hornet recorded the
program as verified, but that enforcement is orthogonal to Hornet's
core integrity/provenance objective.

Thanks


On Thu, Dec 18, 2025 at 9:39 AM ryan foster <foster.ryan.r@...il.com> wrote:
>
> Hi Paul, Blaise,
>
> Thanks for clarifying, that matches my understanding.
>
> My read is Hornet's semantic goal is load-time provenance and integrity: validate the user-generated inputs once the kernel has constructed the final in-kernel program instance (post-relocation, with any integrity-relevant referenced inputs accounted for), and record that result so LSM/policy can make decisions based on a fact the kernel can truthfully assert.
>
> Attaching and linking are separate runtime policy/capability questions. It makes sense that SELinux, IPE, or a BPF LSM program could choose to gate attach/link based on whether Hornet recorded the program as verified, but that enforcement is orthogonal to Hornet's core integrity/provenance objective.
>
> Thanks
>
>
> On Wed, Dec 17, 2025 at 11:33 AM Blaise Boscaccy <bboscaccy@...ux.microsoft.com> wrote:
>>
>> ryan foster <foster.ryan.r@...il.com> writes:
>>
>> > Hi all,
>> >
>>
>> Hi Ryan,
>>
>> > I want to confirm I understand the current semantics, and specific issues
>> > this series is addressing.
>> >
>> > In the signed BPF two step flow, the LSM makes decisions using what is
>> > known at the time of run hooks.  At load time, the only clear fact is "the
>> > loader is signed".  However, if we really want integrity for "the final
>> > program that will execute after relocation, and any inputs as part of the
>> > contract, matches what was signed".  The fact exists after loader runs, so
>> > the kernel could end up allowing and auditing based on the signed loader,
>> > even though it cannot yet truthfully say the runnable payload has been
>> > verified.
>> >
>>
>> Correct.
>>
>> > If this is the right understanding, perhaps we could consider a design that
>> > moves enforcement to the moment the program becomes effective. E.g.  Load
>> > can create a program object, but it is inert by default.  The kernel should
>> > only allow attach or link creation if the kernel has already recorded a
>> > verified record of the final relocated instruction stream plus
>> > referenced state for inputs, is included in the "integrity contract".
>> >
>> > If the referenced state is mutable, then either state must be frozen before
>> > the contract is verified, or any mutation must invalidate verified and
>> > force re-verification and a new policy decision. Otherwise the state is
>> > susceptible to TOCTOU issues.
>> >
>> > Is this the semantic goal Hortnet is aiming for, and is attack or link
>> > creation the intended enforcement point for the "cannot become effective
>> > until verified" rule, instead of trying to make a load time hook represent
>> > final payload verification?
>> >
>> > Thanks
>> >
>> > Regard, Ryan
>>
>>
>> The semantic goal for Hornet is to validate the provenance and integrity
>> of all the user-generated inputs when they are loaded into the kernel,
>> in order to allow users to make intelligent security decisions based
>> on that. IMO, attaching and linking are orthogonal run-time policy issues
>> that are seperate from provenance and data integrity concerns.
>>
>> Allowing or disallowing linking and attaching based on the completeness of
>> signature validation does make sense. That kind of decision would
>> probably be handled by selinux, IPE, or a custom BPF LSM program most
>> likely though.
>>
>> -blaise