WebAssembly-based sandboxing

[DemiMarie]

In containerized environments, kernel-based sandboxing usually does not work (this is #47). An alternative is to use WebAssembly for sandboxing.

[cblichmann]

In containerized environments, kernel-based sandboxing usually does not work (this is #47).

For Sandboxed API, we need the hosting container to allow us to set up eBPF syscall filter rules, which is why I suggested to run --privileged in my comment to the original issue. Nested namespace should generally pose no additional problems though (if one carefully orchestrates them).

An alternative is to use WebAssembly for sandboxing.

Sure, as is using V8 isolates or virtualization based security. Did you mean to comment on #47 instead of opening a new issue? Is this a suggestion for us to implement a WebAssembly backend? ;-)

I'll close this as wontfix, feel free to comment further or re-open.

[DemiMarie]

For Sandboxed API, we need the hosting container to allow us to set up eBPF syscall filter rules, which is why I suggested to run --privileged in my comment to the original issue.

--privileged gives way way way too many privileges to the container, and eBPF is a massive attack surface compared to cBPF. There is a reason that eBPF is often restricted to the superuser.

Nested namespace should generally pose no additional problems though (if one carefully orchestrates them).

At least Flatpak had a recent CVE due to them, and now blocks their creation via seccomp.

Did you mean to comment on #47 instead of opening a new issue? Is this a suggestion for us to implement a WebAssembly backend? ;-)

This is in fact such a suggestion! WebAssembly has numerous other benefits, such as much faster calls between the sandboxed program and the host. I have a hard time imagining how something like libxml2’s SAX API could be sandboxed out-of-process, whereas WebAssembly would make this much easier.

[cblichmann]

All fair points. Namespaces are hard to get right and one can see that they are implemented in the Linux Kernel not in a systematic, "designed" way, but more bolted on. With cBPF vs eBPF I disagree slightly, because it also depends on what you're defending against. Sure, letting any random user process use eBPF may increase the attack surface overall. But the way we're using it, once a sandboxee runs, it will not be able to modify any syscall filters itself or set up new ones. And the eBPF policies are simple and extremely short: no complicated logic, normally just a yes/no decision or maybe an argument check. This should make reasoning about them easier.

Did you mean to comment on #47 instead of opening a new issue? Is this a suggestion for us to implement a WebAssembly backend? ;-)

This is in fact such a suggestion! WebAssembly has numerous other benefits, such as much faster calls between the sandboxed program and the host.

I like this in principle, however, there are many other things we need to refactor/change/improve first, before we can even start tackling this, such as making the Sandbox2 sub-project more modular and decoupling sandbox lifetime management from enforcement. Then, the next natural step would be to port it to e.g. Windows. Moving to WASM would mean that we need to ship a V8 runtime, that the sandboxee's dependencies be compiled with a different C++ toolchain, etc. Not saying this can't be done, but it's a huge undertaking. As for speed, I don't think WASM calls are faster than what we currently have, modulo scheduling issues (sandboxee moving around on different cores vs the host code).

I have a hard time imagining how something like libxml2’s SAX API could be sandboxed out-of-process, whereas WebAssembly would make this much easier.

True libxml2 is huge. But: with Sandboxed API, you can include only those functions that your application actually needs, which is usually a much smaller API surface.

[DemiMarie]

Moving to WASM would mean that we need to ship a V8 runtime, that the sandboxee's dependencies be compiled with a different C++ toolchain, etc. Not saying this can't be done, but it's a huge undertaking.

I was thinking more in terms of Lucet, which is designed for this use-case. Carrying around an entire JavaScript engine would be mega-bloat.