From: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
To: ryan foster <foster.ryan.r@gmail.com>
Cc: James.Bottomley@hansenpartnership.com, akpm@linux-foundation.org,
bpf@vger.kernel.org, corbet@lwn.net, dhowells@redhat.com,
gnoack@google.com, jmorris@namei.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, linux@treblig.org,
mic@digikod.net, paul@paul-moore.com, serge@hallyn.com
Subject: Re: [RFC 00/11] Reintroduce Hornet LSM
Date: Wed, 17 Dec 2025 11:33:55 -0800 [thread overview]
Message-ID: <87v7i4hpi4.fsf@microsoft.com> (raw)
In-Reply-To: <CAHtS32-Zh3knxSdR=DUqQH4rX4QU8ewgu+KHGq6Af3qs9S0FAg@mail.gmail.com>
ryan foster <foster.ryan.r@gmail.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
next prev parent reply other threads:[~2025-12-17 19:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAHtS32-Zh3knxSdR=DUqQH4rX4QU8ewgu+KHGq6Af3qs9S0FAg@mail.gmail.com>
2025-12-17 2:27 ` [RFC 00/11] Reintroduce Hornet LSM Paul Moore
2025-12-17 19:33 ` Blaise Boscaccy [this message]
[not found] ` <CAHtS329aD5DyYSUkcuZXXjZKywqqTHe_1pA6uyaQH=Zwi9kydw@mail.gmail.com>
2025-12-18 17:40 ` ryan foster
2025-12-29 17:12 ` Ryan Foster
2025-12-11 2:11 Blaise Boscaccy
2025-12-15 17:45 ` Ryan Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v7i4hpi4.fsf@microsoft.com \
--to=bboscaccy@linux.microsoft.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=foster.ryan.r@gmail.com \
--cc=gnoack@google.com \
--cc=jmorris@namei.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux@treblig.org \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).