KP Singh <kpsingh@xxxxxxxxxx> writes: > On Tue, Jun 10, 2025 at 11:45 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> KP Singh <kpsingh@xxxxxxxxxx> writes: >> >> > On Mon, Jun 9, 2025 at 10:20 AM Toke Høiland-Jørgensen <toke@xxxxxxxxxx> wrote: >> >> >> >> >> >> > Given that many use-cases (e.g. Cilium) generate trusted BPF programs, >> >> > trusted loaders are an inevitability and a requirement for signing support, a >> >> > entrusting loader programs will be a fundamental requirement for an security >> >> > policy. >> >> >> >> So I've been following this discussion a bit on the sidelines, and have >> >> a question related to this: >> >> >> >> From your description a loader would have embedded hashes for a concrete >> >> BPF program, which doesn't really work for dynamically generated >> >> programs. So how would a "trusted loader" work for dynamically generated >> >> programs? >> > >> > The trusted loader for dynamically generated programs would be the >> > binary that loads the BPF program. So a security policy will need to >> > allow certain trusted binaries (signed with a different key) to load >> > unsigned BPF programs for cilium. >> >> OK, so this refers to a policy along the line of: "Only allow signed BPF >> program except for this particular userspace binary that is allowed to >> load anything"? >> >> > For a stronger policy, the generators can use a derived key and >> > identity (e.g from the Kubernetes / machine / TLS certificate) and >> > then sign their programs using this certificate. The LSM policy then >> > allows verification with a trusted build key and for certain binaries, >> > with the delegated credentials. >> >> And this means "add a separate trusted key on the kernel side that the >> userspace binary signs things with before passing it to the kernel"? >> >> In which case, how does that tie into the original statement I quoted at >> the top of this email? The "trusted loaders are an inevitability" bit? I >> was assuming that the "trusted loaders" in that sentence referred to the >> light-skeleton loader program, but from your reply I'm not thinking > > No trusted loaders are exactly what they mean, trusted blobs of code > that can load BPF programs, these can be loader programs in light > skeletons or trusted user-space binaries. Right, but this patch series has no mechanism for establishing a userspace loader binary as trusted (right?). The paragraph I quoted makes it sound like these are related, and I was trying to figure out what the relation was. But it sounds like the answer is that they are not? -Toke
