Dune - Sandbox for Elixir

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.

Very cool!
I wonder what @arjan thinks of this library, as if memory serves he has been working on ‘sandboxed Elixir’ / ‘DSLs built on top of Elixir’ for quite some time.

This looks very interesting and may provide another answer to a problem that I’m going to run into in a landscape without many existing solutions (that I can see): user customizable business logic. I’ve been looking at Luerl for awhile (nice to see it mentioned in the README). I’m not to this part of my project yet, and won’t be for some time, but it’s nice to see some others working on this problem.

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?

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.

Anyway, best of luck!

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

If you can really lock this down, there could be something interesting with publically hosting LiveBooks, though the really tricky thing to secure is going to be “giving access to limited amounts of memory”

I think it should also be possible to go really low in the stack and disassemble modules, reassemble them with very carefully injected substitutes for certain things (calls, etc).

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. · GitHub

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…

Oh, I wouldn’t propose blocking bytecode,I would propose rewriting bytecode. E.g. rewriting “send” to actually call a safe registry. There are only about 180-is opcodes. Shouldn’t be so terribly hard, ha!

But you’re right. A natively sandboxed vm is probably worth waiting for.

If you can really lock this down, there could be something interesting with publically hosting LiveBooks, though the really tricky thing to secure is going to be “giving access to limited amounts of memory”

Publically shared LiveBooks would be an awesome application indeed! I think it should be possible to have a working version for simply exploring and sharing code. But for it to be actually useful for data analysis, one would need to access not-so-small amounts of memory, be able to have some long-running processing and probably be able to fetch some data from external sources as well. These requirements might be quite hard to reconcile with a publicly hosted service.

I think it should also be possible to go really low in the stack and disassemble modules, reassemble them with very carefully injected substitutes for certain things (calls, etc).

Oh this is a really interesting idea. Thanks @voltone for sharing safeish, I will check it!

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

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