5 ms·

Why acme-client-portable (Lets's Encrypt client) doesn't enable seccomp on Linux

23 points by gbrown_ 10y ago

jwilk 10y ago
The article would be 42% better without the silly images.
- deleted 10y ago
  [deleted]
mixedCase 10y ago
From my point of view, this has a rather easy solution: Hard depend on musl. It's small (so it can be shipped everywhere) and focused on correctness, making it a rather obvious choice for any security-oriented application.
- mixedCase 10y ago
  Can't edit anymore, but after discussing with musl developers, even this is inviable, since musl doesn't offer any guarantees on what syscalls are used on different systems. Apparently the only solution is for seccomp to offer a pledge(2)-like system.
rlpb 10y ago
In summary: seccomp is system (kernel+libc+architecture) specific, but the author wants to maintain something more generic.
aexaey 10y ago
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

23 points by gbrown_ 10y ago

jwilk 10y ago

The article would be 42% better without the silly images.

deleted 10y ago
[deleted]

mixedCase 10y ago

From my point of view, this has a rather easy solution: Hard depend on musl. It's small (so it can be shipped everywhere) and focused on correctness, making it a rather obvious choice for any security-oriented application.

mixedCase 10y ago
Can't edit anymore, but after discussing with musl developers, even this is inviable, since musl doesn't offer any guarantees on what syscalls are used on different systems. Apparently the only solution is for seccomp to offer a pledge(2)-like system.

rlpb 10y ago

In summary: seccomp is system (kernel+libc+architecture) specific, but the author wants to maintain something more generic.

aexaey 10y ago

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