from Hacker News

Open-sourcing Sandboxed API

by gynvael on 3/18/19, 7:28 PM with 15 comments

• by staticassertion on 3/18/19, 10:05 PM

  I tried building something like this for rust, in order to execute closures as a separate process[0].

  I could probably automate it for a struct with a macros so that the API was autosandboxed. Also, it was purely an experiment and is not particularly safe - secrets in the "broker" process would leak to the client, for example. I had plans to deal with at least some of these issues using a build.rs to generate a separate binary that could be exec'd but I stopped caring.

  I wonder how this sandboxapi gets around that?

  The reason I didn't bother was because I found that constructing the sandbox was the hard part, not executing the code in it - how do you detect what the code needs to do in the sandbox? You end up too tight or too loose.

  Also, performance is miserable if you have to fork/exec every single time. So you may be tempted to cache the process across executions but that comes with its own pains. Again, curious how this is dealt with in sandboxapi.

  Personally, I want to see sandboxing support at a language level. I imagine a language, perhaps like Pony, which has isolated units of execution that connect via some form of RPC/message passing. With a type system that "taints" types based on actions, basically a capability type that propagates upwards, you could generate seccomp filters for every unit of execution. Pony seems like it's actually not far from this, from what I could tell.

  Sandboxing in a language like this is a matter of moving the execution unit out of process, which shouldn't be that hard.

  [0] https://github.com/insanitybit/sandbox

• by josephg on 3/18/19, 11:01 PM

  Neat! I wonder how this would compare to the equivalent WASM implementation.

  With WASM, you wouldn't need to run the sandboxed code in a separate execution context. And you shouldn't need any OS-specific code to isolate the sandboxed executable. The whole thing would be conceptually simpler; although you'd need to pull in a WASM runtime. The actual code would run a bit slower in order for the WASM VM to do bounds checks and so on. But I think function calls across the WASM boundary would be way faster than the sandboxed IPC bridge that blog post suggests. Also a WASM version would let you build your sandboxed bundle once and run it anywhere, which is neat.

  So I get the sense that a WASM version of this would be simpler and more portable but have a different performance profile. Are there other considerations here? It'd be a cool experiment to play with.

• by AndrewGaspar on 3/18/19, 9:44 PM

  Ah, when I got to the code snippet, I was hoping I'd see that you didn't have to change any code, that SAPI could generate the precise interface of the library you're using, but it looks like the code you have to write is a pretty big divergence from the original library API.

• by pjmlp on 3/19/19, 11:52 AM

  > So far, only Linux is supported. We will look into bringing Sandboxed API to the Unix-like systems like the BSDs (FreeBSD, OpenBSD) and macOS. A Windows port is a bigger undertaking and will require some more groundwork to be done.

  Oh well.