On Thu, Oct 25, 2018 at 5:49 PM, Andy Lutomirski <[email protected]> wrote: >> On Oct 25, 2018, at 5:35 PM, Kees Cook <[email protected]> wrote: >> >>> On Fri, Oct 26, 2018 at 12:00 AM, Andy Lutomirski <[email protected]> >>> 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
