On 6/1/21 2:55 PM, Kees Cook wrote:
On Thu, May 20, 2021 at 10:56:13AM +0200, Christian Brauner wrote:
On Thu, May 20, 2021 at 03:16:10AM -0500, Tianyin Xu wrote:
On Mon, May 17, 2021 at 10:40 AM Tycho Andersen <tycho@tycho.pizza> wrote:
On Sun, May 16, 2021 at 03:38:00AM -0500, Tianyin Xu wrote:
On Sat, May 15, 2021 at 10:49 AM Andy Lutomirski <luto@xxxxxxxxxx> wrote:
On 5/10/21 10:21 PM, YiFei Zhu wrote:
On Mon, May 10, 2021 at 12:47 PM Andy Lutomirski <luto@xxxxxxxxxx> wrote:
On Mon, May 10, 2021 at 10:22 AM YiFei Zhu <zhuyifei1999@xxxxxxxxx> wrote:
From: YiFei Zhu <yifeifz2@xxxxxxxxxxxx>
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. :)
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...
[...] 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
