On Tue, Jul 6, 2021 at 10:30 AM Alan Jowett <Alan.Jowett@xxxxxxxxxxxxx> wrote: > > BPF folks, > > Quick question: Has anyone considered using signing of BPF programs as compromise between completely denying non-root from loading eBPF programs and permitting non-root to load any eBPF programs? > > Problem statement: > A large set of security issues have arisen because of permitting non-root to verify and load eBPF programs into the kernel. These range from Specter style speculative load side channel attacks to verification failures. The desire exists to permit programs that use eBPF to run as non-root as an effort to run with least privilege, but this conflicts with the desire to limit eBPF program loading to root only. > > Proposal: > Enable signing enforcement of eBPF programs (https://lwn.net/Articles/853489/) and permit root to set a policy that permits non-root to only load eBPF programs signed by root. This would allow root to delegate permission to load specific eBPF programs to a non-root entity while continuing to block loading of arbitrary eBPF programs. Root could then verify the provenance of eBPF programs and then sign them only if they are from a safe source and have been compiled with appropriate speculative load hardening. This approach would appear to give the benefits of least privilege while also controlling what is loaded into the kernel address space. > > Background: > The eBPF for Windows (https://github.com/microsoft/ebpf-for-windows) team is exploring security hardening options and one of the options on the table is to use signing to restrict loading of eBPF programs to those designated as trusted. The desire exists to maintain a similar security model on all platforms on which eBPF is supported, hence reaching out to you folks. > > Thoughts or feedback? In general it all makes sense to me. The only confusing bit is "signed by root". I don't think such model exists today. At least for bpf programs the idea was to follow a signing process mostly similar to kernel module signing. The user that signed it is not recorded in the signature. Whoever has the key can sign it. The kernel would verify the signature from the key ring. The questions would be whether bpf needs its own key ring or not. Some folks proposed to delegate the final decision to another bpf prog. Like the kernel would verify the signature, but things like key ring and what to do with validation outcome would be delegated to a special prog. In such case an unpriv process loading progs that are signed with a certain key could be allowed to proceed even when progs are of tracing type. The libbpf-tools and pre-compiled bpftrace scripts would benefit. I think it would fit exactly to what you're proposing. These details need to be worked out, of course.
