> On Sep 7, 2020, at 3:15 AM, Christian Brauner <christian.brauner@xxxxxxxxxx> wrote: > > On Fri, Sep 04, 2020 at 04:31:44PM -0400, Gabriel Krisman Bertazi wrote: >> Syscall User Dispatch (SUD) must take precedence over seccomp, since the >> use case is emulation (it can be invoked with a different ABI) such that >> seccomp filtering by syscall number doesn't make sense in the first >> place. In addition, either the syscall is dispatched back to userspace, >> in which case there is no resource for seccomp to protect, or the > > Tbh, I'm torn here. I'm not a super clever attacker but it feels to me > that this is still at least a clever way to circumvent a seccomp > sandbox. > If I'd be confined by a seccomp profile that would cause me to be > SIGKILLed when I try do open() I could prctl() myself to do user > dispatch to prevent that from happening, no? > Not really, I think. The idea is that you didn’t actually do open(). You did a SYSCALL instruction which meant something else, and the syscall dispatch correctly prevented the kernel from misinterpreting it as open().
