OP is understandably upset about seccomp filters not being portable between different distributions and architectures. Fair enough. But there's another glaring

OP is understandably upset about seccomp filters not being portable between different distributions and architectures. Fair enough. But there's another glaring issue here. This app's seccom filter was written by a fairly security-conscious developer, who goes as far as saying he'd ideally want to reproduce any bug reports involving filter changes, and have serious unease accepting patches with new "allow" statements blindly. In other words, we can consider this seccomp filter to be as good as it gets, or close. And yet, this filter allows[1]: - Full network access (socket/connect/bind/recvfrom/sendto); - Full local file-system access (open/read/write/close/mmap/unlink/rename); - Access to a long-time vulnerable system call that was only fixed relatively recently, i.e. probably fix still isn't applied on quite a number of systems out there (madvise) [2]. That's plenty of rope, if you ask me. How one could argue that process having all of permissions above is "sandboxed" in any meaningful way? [1] https://github.com/kristapsdz/acme-client-portable/blob/master/sandbox-seccomp.c https://github.com/kristapsdz/acme-client-portable/blob/mast... [2] https://news.ycombinator.com/item?id=12756006 https://news.ycombinator.com/item?id=12756006