The EEF(Erlang Ecosystem Foundation) was prepared and collected interesting info in topic which is dedicated to Erlang secure coding. What information do you think is missing in this topic? What secure coding problems have you encountered in practice and how you dealt with it?
7 Likes
It’s a little disappointing that the WG punts on sandboxing. This seems like a critical feature for the BEAM. If the “BEAM as an OS for code” analogy sticks up, we should have access control between (Erlang lightweight) “processes”.
Would the WG consider taking this up in the future? Or is the WG section on sandboxing just descriptive of the “current state of the art”?
3 Likes
It would be great to have BEAM-level sandboxing features, and there have been proposals in the past. But this will likely require changes deep inside the VM, and the OTP team would have to be on board with maintaining those changes going forward. At this point I don’t think the EEF would have sufficient resources to be able to commit to supporting the team in the long run. Maybe after some smaller contributions and with some corporate backing it can be considered one day.
This document is indeed supposed to document best practices given the current state of things. It is similar to secure coding standards that exist for other languages, such as those by SEI CERT.
I just opened a PR yesterday. Anyway, the WG is planning a call on Nov 17, and anyone is welcome to join and propose projects or contribute. Check out the EEF Slack for details.
3 Likes
What are the use case(es) for seeing BEAM as an OS for code? , which would motivate the implementation of access control on Erlang process level? And you would also need access control for function calls and ets-tables in that case.
There has been several attempts on making a Safe Erlang , Master Thesis workers at Ericsson for example but this was in the late 1990:ies.
I think you have to be in control of the SW you run in each Erlang VM (BEAM) and in a cluster of BEAMs as well.
I am still waiting for the use case that can motivate (and finance) an implementation of “safe” Erlang.
5 Likes
I am still waiting for the use case that can motivate (and finance) an implementation of “safe” Erlang.
Fair enough. I think the only compelling use-case is something akin to containerization, in the way that Java has produced Tomcat and even (going further) OSGI (Eclipse). I think those technologies are intended to allow multiple applications to run in the same VM, with separate fire-walled class loaders, etc.
That being said, I have yet to see either Tomcat being used commercially as anything more than a glorified web service framework (with up to 100 stack frames between you and the socket), hosting a single service in Docker, which kind of defeats the purpose, if you are trying to get to one VM per hardware node!
So I agree that unless there is sponsorship, these use cases can otherwise be (and are) satisfied by OS-level containerization, such as via Docker or Jails. And the Erlang community is sufficiently small (relative to Java/Ruby/Python) that an OTP PaaS would be an unlikely target for venture capital 
3 Likes