4 ms·

It’s readily apparent: More efficient: using wasm has a necessary compilation or interpretation overheard. Seccomp doesn’t. Simpler: wasm requires deploying r

It’s readily apparent: More efficient: using wasm has a necessary compilation or interpretation overheard. Seccomp doesn’t. Simpler: wasm requires deploying running an entire wasm runtime, likely >= 50K LOC in additional complexity and attack surface. Seccomp uses a small 100 line shim.

imtringued 6y ago
You can run WASM to grant fine grained access to certain APIs. You might be able to do this with a sidecar that provides the API over HTTP and then let the untrusted process only access the side car but why do this when you can just grant API access to a WASM module? From the perspective of the third party user the API can be called directly via a function instead of doing a HTTP request.
devwastaken 6y ago
"readily apparent" is not good evidence. Security isn't as simple as number of lines of code. You need actual in depth analysis to even know the attack surface. The reason why people view wasm as more secure is the runtimes used for it are VM's that control execution at an instruction level along with the wasm instruction set being far simpler than x86. Not saying wasm is magically secure because of this, there's not much actual security analysis of existing runtimes - but there are good reasons for why it can be viewed as more secure.
- CyberRabbi 6y ago
  Wasm execution doesn’t exist in the abstract. Lucet, the vm in question, does no theoretical instruction-level mitigations of which you speak. It does, however, expose a larger attack surface than simply using seccomp (not seccomp-bpf).
  - the_mitsuhiko 6y ago
    By definition a WASM runtime running within seccomp does not increase the attack surface. That's in fact the whole point of layering such systems. I'm not exactly sure what your point is or why you're talking about seccomp-bpf here.

4 ms·

It’s readily apparent: More efficient: using wasm has a necessary compilation or interpretation overheard. Seccomp doesn’t. Simpler: wasm requires deploying r

by CyberRabbi 6y ago

imtringued 6y ago
You can run WASM to grant fine grained access to certain APIs. You might be able to do this with a sidecar that provides the API over HTTP and then let the untrusted process only access the side car but why do this when you can just grant API access to a WASM module? From the perspective of the third party user the API can be called directly via a function instead of doing a HTTP request.
devwastaken 6y ago
"readily apparent" is not good evidence. Security isn't as simple as number of lines of code. You need actual in depth analysis to even know the attack surface. The reason why people view wasm as more secure is the runtimes used for it are VM's that control execution at an instruction level along with the wasm instruction set being far simpler than x86. Not saying wasm is magically secure because of this, there's not much actual security analysis of existing runtimes - but there are good reasons for why it can be viewed as more secure.
- CyberRabbi 6y ago
  Wasm execution doesn’t exist in the abstract. Lucet, the vm in question, does no theoretical instruction-level mitigations of which you speak. It does, however, expose a larger attack surface than simply using seccomp (not seccomp-bpf).
  - the_mitsuhiko 6y ago
    By definition a WASM runtime running within seccomp does not increase the attack surface. That's in fact the whole point of layering such systems. I'm not exactly sure what your point is or why you're talking about seccomp-bpf here.