The bytecode sandbox approach has been attempted: GitHub - robinhilliard/safeish: NOT FOR PRODUCTION USE: Safe-ish is an experimental sandbox for BEAM modules that examines and rejects BEAM bytecode containing instructions that could cause side effects. You can provide an optional whitelist of opcodes and functions the module is allowed to use.

It turns out to be quite difficult to implement at that level, because of the various ways high-level language features are compiled down to bytecode, after the various optimizations and handling of special cases. Once all the sandbox escape paths have been fully blocked (if that ever happens) I suspect it will also block many perfectly harmless and possibly essential language features just because they happen to compile down to bytecode that is considered too powerful.

Personally I would stick with Luerl until the BEAM offers a native, runtime sandboxing feature…

You may want to check out this video of @robinhilliard talking about the experiment (with a cameo by yours truly)…

Interesting. There has been very little work in this area. In Java, sandboxes (class loader + security policy) have facilitated the popularity of Hadoop and large scale distributed computing workloads. Definitely a small but very interesting step in that that direction.

Thanks for your interest in Dune!

I noticed that the README in the repo mentions the customizable business logic, but your message here really only says it’s targeted more a fun/educational projects. Is that discrepancy due to really what you’re targeting or just the fact that this is very early stage?

Customizable business logic is definitely a use case I have in mind for Dune, and I’m sorry that my message might have given a wrong impression (squeezing a readme in a short forum post can be a bit difficult). This was more about my initial motivation for starting the project it in the first place: I would be happy to see Dune help build projects that might play a role in Elixir adoption, like tutorials/games which could help people get a taste of Elixir without any need to install. But this doesn’t impact the design of the library in any way: Dune is a generic sandbox and is totally agnostic about the use case.

It will be interesting to see how this plays out and how well it performs… my other concern about this sort of thing on the BEAM. There’s so much more interest in writing BEAM languages than writing languages that run on the BEAM (if that distinction makes sense) that it does have me wondering if these sandboxed kind of runtimes are really viable on the BEAM.

Regarding the viability aspect, I think the BEAM has some strong advantages over other stacks in some regards: light-weight processes with a pre-emptive scheduling and all the introspection capabilities make it a breeze to run the code in isolation within limited resources: memory, CPU and time. Some other aspects, like the way atoms or modules are globally shared on the VM, were more tricky to handle and needed some convoluted workarounds to support. Regarding Elixir in particular, having AST manipulation as a first-class citizen helped a lot, even if it comes with its challenges because the AST can be rather complex: there are many cases to be considered to properly restrict what can be executed.

I hope that Dune will be able to help when you reach the stage where you need a sandbox, and I look forward to getting feedback if there is anything missing/would need to be fixed

Hi Sabiwara,

To be clear, Bram was involved in successfully hacking my attempts to make byte code secure with Safeish (a late December rainy holiday project for me), and he in no way condones or supports this approach, it is entirely my fault :-).

Cheers,
Robin