Why acme-client-portable (Lets's Encrypt client) doesn't enable seccomp on Linux
github.com
github.com
It's small (so it can be shipped everywhere) and focused on correctness, making it a rather obvious choice for any security-oriented application.
Apparently the only solution is for seccomp to offer a pledge(2)-like system.
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/mast...