Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

This paper is an easy read, but it's basically just restating the premises of eBPF:

* Most programs can't be expressed in verified eBPF.

* The verifier functions, to the extent it does, in large part by rejecting most programs (and implicitly limiting the uses to which eBPF can be put).

* This is "extension code", and by definition, it interacts with the unsafe, unverified C code that the kernel is built out of.

(In addition to helpers, most serious eBPF-based systems also interact extensively with userland code, which is also not verified, and might even be memory-unsafe, though that's increasingly less likely).

It follows from these premises that vendors should be careful about enabling non-root access to eBPF; when you do that, you really are placing a lot of faith in the verifier. And: most people don't allow non-root eBPF. The verifier is in an uncomfortable place between being a security boundary and a reliability tool.

I'd argue that most of the benefit of eBPF is that you're unlikely to panic your kernel playing with it. Ironically, that's a feature you might not get out of signed, userland-verified, memory-safe Rust code.

Surely if you are allowing non-root eBPF then security of the programs is one of your least worries? Given all the implicit privilege escalation that comes with allowing non-root to spy on everything the kernel does.

Unprivileged BPF is used for socket filters, for programs to BPF-extend themselves. It wasn't ever the case that unprivileged eBPF would allow you to, say, load a TC filter and read everybody's traffic.

Ok but you can like put a tracepoint on read/write and peek at what’s going through those, no?

I have no idea, because every system I've ever worked on has disabled unprivileged eBPF.

Nope. Tracepoint eBPF programs require root to load always. For eBPF you select a program type, and that limits what you can do (aka what helper functions are available to you) and what privileges are required.

> ows from these premises that vendors should be careful about enabling non-root access to eBPF;

The thing is that it would be really nice to be able to set up a seccomp filter without a suid :\

seccomp does not use the eBPF userspace interface or any of the associated permission checks. seccomp (and also the classic socket filter interface) take cBPF (classic BPF), with no privilege checks; they use completely separate verification logic for this cBPF bytecode (the eBPF verifier is not involved IIRC), and then the cBPF code is (on almost all architectures) translated into eBPF. The eBPF kernel component is then only responsible for execution/JITting of this already-verified code, nothing else.

Makes sense, thanks.

Reply on news.ycombinator.com