A cluster of Erlang nodes in distribution don't have a security boundary once they're connected. Neither do two threads in the same process in a traditional system.
If that's an issue, and I can see why it might be for some, you'll need to use something other than Erlang distribution to connect your cluster.
You can patch out the explicit rpc server, but I'm not sure that you can patch out receiving functions (maybe removing the code that deserializes them from external term format would work?), and you'd need to audit the whole thing to ensure nothing ever calls a function it receives.
I'm not a security guy, so I can't speak for what their concerns would be.
I think my concern would be more in the realm of, you're inherently relying on whatever peer authentication system BEAM uses (and it being bug/exploit-free), to determine whether an RPC call can suddenly inject new code into a running system.
In my experience good security is a lot like an onion - there's lots of layers and generally some crying.
If we consider a "non-BEAM" system that runs on say JVM, or even a "scripting" runtime (e.g. PHP, Python, Ruby, NodeJS) - you typically have a number of elements that (can) contribute to making the code that runs, relatively immutable outside of a deployment event (e.g., restricting access to ssh/sftp/etc protocols; varying types of filesystem permissions; readonly volumes; container filesystems; etc)
Do other systems have similar "run arbitrary code" vulnerabilities? Sure. Allowing uploaded content to be executed by the PHP runtime is a classic example. But there's almost no legitimate purpose for this, it's almost certainly a configuration error/mistake, and it's relatively trivial to prevent it completely.
You're not supposed to open the Erlang RPC port to the open Internet, and there is a modicum of security barrier with its cookie if you're so inept as to run Erlang on a non-firewalled server on the open Internet.
You don't need security people for basic sysadmin know how.
So? How is this specifically relevant to the topic at hand?
If you have someone malicious in your internal network that can connect to your Erlang nodes, you have bigger issues that them connecting to your Erlang nodes.
I don't see the point of your original comment. Having an out-of-the-box RPC mechanism means you gotta secure it as you secure any other internal service. That's sysadmin 101.
> I don't see the point of your original comment. Having an out-of-the-box RPC mechanism means you gotta secure it as you secure any other internal service. That's sysadmin 101
Most RPC systems can't inject code into the running system dynamically. That's the point of my original post.
Yeah, but what happens when your local web browser is tricked into opening a socket to the local Erlang instance by a malicious web page? That's the kind of thing that keeps security professionals up all night.
It’s a binary protocol though, which means that this specific scenario isn’t an issue as far as I’m aware (the only ways of making arbitrary JS-controlled network requests are XHR/fetch(), which is only HTTP, and WebSockets, which have a handshake mechanism to ensure that the other side is really expecting a WS connection, which Erlang won’t be).
It's a bit concerning if it's only "security guys" seeing issues with this approach.