4 ms·

>From what I've seen, the best understanding right now is that the process is the smallest defensible unit of isolation. In what scenario would you be more com

>From what I've seen, the best understanding right now is that the process is the smallest defensible unit of isolation. In what scenario would you be more comfortable running a potentially malicious process versus a potentially malicious WASM code behind a API sandbox where you control the exposed APIs. Sure there are process level sandboxes but that seems like a much larger bug surface area with expertise outside of the domain of people building the apps, compared to a WASM sandbox with a host app defined bridge API.

the8472 6y ago
> Sure there are process level sandboxes but that seems like a much larger bug surface area A process sandbox allows you to pass through syscalls you deem harmless without reimplementing them and only building the bridge API for things that require complex policies. With wasm you need to implement wrappers for everything. Let's say your wasm module is pure compute and does IPC via shared memory locks. You now at least have to implement the locking API. In the process sandbox case you only whitelist the futex syscall and that's it. And in practice you'll have to use the process sandbox anyway due to CPU vulnerabilities or bugs in the bridge API.
- rubber_duck 6y ago
  >A process sandbox allows you to pass through syscalls you deem harmless without reimplementing them and only building the bridge API for things that require complex policies. With wasm you need to implement wrappers for everything. Yeah except you have to know what OS your application is going to run on, kernel version, set up the sandbox correctly and trust that the kernel doesn't have any privilege escalation bugs - likely none of which is your area of expertise as an application developer. A sandbox runtime with exposed APIs is much closer to your domain and you can model it to be much more domain specific so the surface you need to wrap should be smaller.
  - the8472 6y ago
    I think the surface mostly depends on how much you want to give the sandboxed application, not on the sandboxing technology you choose. If want to build something emulating the capabilities of a desktop operating system including gfx acceleration (e.g. webgpu) then it will be much larger than some isolated compute function in the fashion of network edge workers. I am not aware of a single CVE against openbsd's pledge. On the other hand there are plenty of javascript engine escapes.
    - saagarjha 6y ago
      Part of that is certainly because nobody is actively attacking OpenBSD's pledge, while JavaScript engines are under constant attack. (FWIW, every major JavaScript engine utilizes a platform sandbox that provides pledge-like functionality.)

the8472 6y ago

> Sure there are process level sandboxes but that seems like a much larger bug surface area A process sandbox allows you to pass through syscalls you deem harmless without reimplementing them and only building the bridge API for things that require complex policies. With wasm you need to implement wrappers for everything. Let's say your wasm module is pure compute and does IPC via shared memory locks. You now at least have to implement the locking API. In the process sandbox case you only whitelist the futex syscall and that's it. And in practice you'll have to use the process sandbox anyway due to CPU vulnerabilities or bugs in the bridge API.

rubber_duck 6y ago
>A process sandbox allows you to pass through syscalls you deem harmless without reimplementing them and only building the bridge API for things that require complex policies. With wasm you need to implement wrappers for everything. Yeah except you have to know what OS your application is going to run on, kernel version, set up the sandbox correctly and trust that the kernel doesn't have any privilege escalation bugs - likely none of which is your area of expertise as an application developer. A sandbox runtime with exposed APIs is much closer to your domain and you can model it to be much more domain specific so the surface you need to wrap should be smaller.
- the8472 6y ago
  I think the surface mostly depends on how much you want to give the sandboxed application, not on the sandboxing technology you choose. If want to build something emulating the capabilities of a desktop operating system including gfx acceleration (e.g. webgpu) then it will be much larger than some isolated compute function in the fashion of network edge workers. I am not aware of a single CVE against openbsd's pledge. On the other hand there are plenty of javascript engine escapes.
  - saagarjha 6y ago
    Part of that is certainly because nobody is actively attacking OpenBSD's pledge, while JavaScript engines are under constant attack. (FWIW, every major JavaScript engine utilizes a platform sandbox that provides pledge-like functionality.)