Conversation

TIL Linux contains a microkernel-like VM that runs general purpose verified state machine code based on BPF (which no longer has much of anything to do w/ Berkeley or packets or filters). It underlies Chrome's sandbox and powers FB, Netflix, & Cloudflare. brendangregg.com/blog/2019-12-0

179

539

Replying to

and

Serious question: is this a bug or feature? (I could argue both sides.) Not so serious question: How many ASN.1 parsers does a kernel need?

Replying to

and

my container friends in the know tell me it's the bee's knees for significantly raising the sandbox bar on syscalls.

Replying to

and

Worth noting seccomp-bpf uses a small subset of cBPF (classic BPF) designed to minimize attack surface rather than eBPF. eBPF has a lot of attack surface and eBPF support for seccomp-bpf wasn't accepted. Exposing eBPF to unprivileged code substantially increases attack surface.

Replying to

But with seccomp bpf the program is not controlled by the attacker, doesn't it? Why is it considered attack surface?

Replying to

It's available to an attacker outside of a very lean sandbox where loading a seccomp-bpf filter isn't allowed. It's both possible and sensible for seccomp-bpf filters to be layered. It makes sense to use a weak filter for a generic app sandbox and then proper strict ones inside.

3:10 AM · May 18, 2020Twitter Web App

Replying to

Applications / libraries can divide themselves up into sandboxed processes using seccomp-bpf. It's exposed to unprivileged code by design, as long as the no_new_privs flag is set. It makes sense to drop the ability to use it after initialization in an app putting in the effort.