arnomi
I find myself quite often in the following situation.
Colleague: “Elixir/Erlang is problematic because we cannot secure the VM (i.e. Beam). It is vulnerable to code injection because anybody that gets to the system can start a remote shell and change running code without anybody noticing it. On the JVM in contrast this is not possible.”
To some extend this argument is correct. The JVM (and most other runtime systems) don’t offer the debug or cluster capabilities BEAM offers which make debugging a lot harder but also works in favor of securing the system (completely neglecting the code that is actually running withing the VM).
My question is: What are good arguments in favor of the security of BEAM and what are best practices to secure a running system (both in cluster mode and as a single isolated VM) as much as possible?
Where Next?
Trending in Discussions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #elixirconf-eu
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
**Building the future of software with AI, trust, and human connection.**
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
First Post!- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
NobbZ
To be honest… But once the attacker has access to the system they can do anything… I do not need to alter the JVM to read its memory. To sniff network traffic, to get hands on certificates, to well, achieve about everything…
An attacker that came thus far, does not care anymore about the runtime. They care about the tasty stuff. SSH keys, config data (which usually contains passwords for DB or other external services), business data…
Most Liked
garazdawi
If you remove those debugging capabilities, by for instance not running distributed Erlang and not using run_erl/to_erl, you get into a very similar state as the JVM. You cannot debug, but you also cannot do code injection.
josevalim
Right, that’s my point. The distribution and debug features are opt-in. When you start the VM, they are not enabled by default. You don’t have to do anything.
idi527
Distribution over vpn is another alternative to tls (which I find simpler since no certificate management), wireguard will probably be integrated into the linux kernel “soon” (maybe in 5.0?). There’s also tinc, but it’s slower. I can publish a demo repo with my setup for both, if there is any interest. And if your hosting provider also provides a private network between vms as a service, then it’s even easier.
When I don’t need the distribution, I add
to the config to avoid epmd binding to all network interfaces. I also close all ports by default, and only leave the ones necessary for the application usage open.
Last Post!
dimitarvp
Oh, I see. Sucks to have lived with a wrong belief for so long.
Thank you!