9 ms·

You keep repeating this, but it's simply not true. The syscall surface is zero by default. WASI of course expands that by a lot, but sane WASI implementations

You keep repeating this, but it's simply not true. The syscall surface is zero by default. WASI of course expands that by a lot, but sane WASI implementations require restrictive whitelisting of available resources like specific files or directories that can be accessed. (wasmtime-wasi does this well,for example). The whole wasi spec is aiming for capability based security, including things like only providing access to pre-opened sockets. All production deployments of server side Wasm I have seen have very tight scoping. Sandboxing on Linux, in contrast, is a complicated mess, with a myriad of partial and leaky solutions (SELinux, Apparmor, Docker, Snap, Flatpak, ...) . Having a good cross platform toolkit is completely out of reach. The only OS that has comparable sandboxing that is practical is Fuchsia.

pjmlp 5y ago
And will keep repeating ad eternum given the fake security sales from Webassembly, for God's sake evem the standard has a security section mentioning possible issues not addressed. There is no magic in WASM, only when the only thing it does is warming up a CPU.
- the_duke 5y ago
  I'm happy to have a technical discussion, but your comments always stop at "Wasm bad", without countering the arguments.
  - kaba0 5y ago
    I would be interested in the previously mentioned claims like “wasm can’t protect against rowhammer” —- while perhaps not an easily exploited vulnerability, and likely every current sandbox tech is vulnerable, is there anything specific to wasm that would help here? Also, how does wasm relate to traditional sandboxes that “just” hijack system calls? Is there a difference?
  - pjmlp 5y ago
nix0n 5y ago
Is this true of server side only, or is there a practical solution for locking down JS within the browser?
- the_duke 5y ago
  Wasm has no access to any browser APIs by default, so yes. You can expose the required functionality via JavaScript bridges. The current Rust (wasm-bindgen) and C/C++ (emscripten) tooling exposes the the whole browser API by default though, which isn't ideal.
astrange 5y ago
Darwin has quite good sandboxing, although how to actually use it isn't documented.

pjmlp 5y ago

And will keep repeating ad eternum given the fake security sales from Webassembly, for God's sake evem the standard has a security section mentioning possible issues not addressed. There is no magic in WASM, only when the only thing it does is warming up a CPU.

the_duke 5y ago
I'm happy to have a technical discussion, but your comments always stop at "Wasm bad", without countering the arguments.
- kaba0 5y ago
  I would be interested in the previously mentioned claims like “wasm can’t protect against rowhammer” —- while perhaps not an easily exploited vulnerability, and likely every current sandbox tech is vulnerable, is there anything specific to wasm that would help here? Also, how does wasm relate to traditional sandboxes that “just” hijack system calls? Is there a difference?
- pjmlp 5y ago

nix0n 5y ago

Is this true of server side only, or is there a practical solution for locking down JS within the browser?

the_duke 5y ago
Wasm has no access to any browser APIs by default, so yes. You can expose the required functionality via JavaScript bridges. The current Rust (wasm-bindgen) and C/C++ (emscripten) tooling exposes the the whole browser API by default though, which isn't ideal.

astrange 5y ago

Darwin has quite good sandboxing, although how to actually use it isn't documented.