Re: [RFC PATCH bpf-next seccomp 00/12] eBPF seccomp filters

On 6/1/21 2:55 PM, Kees Cook wrote:

On Thu, May 20, 2021 at 10:56:13AM +0200, Christian Brauner wrote:

quoted

On Thu, May 20, 2021 at 03:16:10AM -0500, Tianyin Xu wrote:

quoted

On Mon, May 17, 2021 at 10:40 AM Tycho Andersen [off-list ref] wrote:

quoted

On Sun, May 16, 2021 at 03:38:00AM -0500, Tianyin Xu wrote:

quoted

On Sat, May 15, 2021 at 10:49 AM Andy Lutomirski [off-list ref] wrote:

quoted

On 5/10/21 10:21 PM, YiFei Zhu wrote:

quoted

On Mon, May 10, 2021 at 12:47 PM Andy Lutomirski [off-list ref] wrote:

quoted

On Mon, May 10, 2021 at 10:22 AM YiFei Zhu [off-list ref] wrote:

quoted

From: YiFei Zhu <redacted>

Based on: https://urldefense.com/v3/__https://lists.linux-foundation.org/pipermail/containers/2018-February/038571.html__;!!DZ3fjg!thbAoRgmCeWjlv0qPDndNZW1j6Y2Kl_huVyUffr4wVbISf-aUiULaWHwkKJrNJyo$

This patchset enables seccomp filters to be written in eBPF.

Before I dive in, I do want to say that this is very interesting work.
Thanks for working on it, even if we're all so grumpy about accepting
it. :)

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Supporting eBPF filters has been proposed a few times in the past.
The main concerns were (1) use cases and (2) security. We have
identified many use cases that can benefit from advanced eBPF
filters, such as:

I haven't reviewed this carefully, but I think we need to distinguish
a few things:

1. Using the eBPF *language*.

Likely everyone is aware, but I'll point out for anyone new reading this
thread: seccomp uses eBPF under the hood: all the cBPF is transformed to
eBPF at filter attach time. But yes, I get the point: using the _entire_
eBPF language. Though I'd remind folks that seccomp doesn't even use
the entire cBPF language...

quoted

[...] but Andy's point stands that this brings a slew of issues on
the table that need clear answers. Bringing stateful ebpf features into
seccomp is a pretty big step and especially around the
privilege/security model it looks pretty handwavy right now.

This is the blocker as far as I'm concerned: there is no story for
unprivileged eBPF. And even IF there was a story there, I find the rate
of security-related flaws in eBPF to be way too high for a sandboxing
primitive to depend on. There have been around a dozen a year for the
last 4 years:

$ git log --oneline --no-merges --pretty=format:'%as %h %s' \
    -i -E \ --all-match --grep '^Fixes:' --grep \
    '(over|under)flow|\bleak|escalat|expos(e[ds]?|ure)\b|use[- ]?after[- ]?free' \
    -- kernel/bpf/ | cut -d- -f1 | sort | uniq -c
       4 2015
       4 2016
      13 2017
      16 2018
      18 2019
      12 2020
       6 2021

I just can't bring myself to accept that level of risk for seccomp.

I just want to clarify that the patch is not supposed to add more risks to seccomp.


The vulnerabilities of ebpf are inherently there as long as ebpf is supported, no matter whether Seccomp supports ebpf filters or not. If ebpf is of concern, one can turn off ebpf completely and Seccomp ebpf won’t be available. Otherwise, the vulnerabilities are in your socket filters anyway.

(And
yes, this might be mitigated by blocking the bpf() syscall within a
filter, but then eBPF seccomp would become kind of useless inside a
container launcher, etc etc.)

This is an interesting point. I think the main concern is still about the additional risks (which I responded above).


I responded to Christian Brauner earlier about the security model. Basically, the implementation is as restrictive as user notifier and ptrace. For example, if CAP_BPF is not there, the container won’t be able to load ebpf filters with tracing helpers.


In fact, one can load the ebpf filter first and then block the bpf syscall (if it makes things more secure).


Best,

Jinghao

-Kees