On Thu, Oct 25, 2018 at 5:49 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Oct 25, 2018, at 5:35 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> >>> On Fri, Oct 26, 2018 at 12:00 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>> You could bite the bullet and add seccomp eBPF support :) >> >> I'm not convinced this is a good enough reason for gaining the eBPF >> attack surface yet. > > Is it an interesting attack surface? It’s certainly scarier if you’re worried about attacks from the sandbox creator, but the security inside the sandbox should be more or less equivalent, no? Yeah, I'm more worried about the creator: I don't want kernel exploits via seccomp APIs. :P There have been kind of a long list of eBPF-related flaws, so I'd really rather not tie seccomp to it. As for sandbox escapes, I don't think there's too much concern, but I do worry about "unexpected" situations exposed by eBPF (i.e. maps or functions not doing what was expected, or allowing map manipulation from outside). seccomp cBPF is pretty self-contained right now, so I'd like a strong reason to justify the increase in code complexity and related attack surface. -- Kees Cook
