[erlang-patches] What's cooking in erlang/otp (2010-03-22)

[Jayson Vantuyl]

> No they haven't. Not if you want to actually utilize the advertised  
> features
If you'd like to spearhead the effort, feel free. The current  
Distributed Erlang implementation uses binary_to_term internally, so  
you can probably start by setting the safe flag there.

Your first problem is that node names and many atoms are embedded in  
some unique structures (pids, refs, funs), so you'll have to create an  
infrastructure to allocate them when nodes are trusted, or the safety  
won't be too useful.  Then you can start securing things like Rex and  
RPC.

As for "advertised features", I question that entire line of  
reasoning. Of course Erlang doesn't give you the tools to utilize all  
of the advertised features PLUS your additional feature. The  
guarantees of advertising end when you add requirements.

> of the platform. Providing a means to communicate outside the VM and  
> then serialize terms is hardly "all the instruments" needed to  
> secure a platform.
That's all that the current distribution is based on. Of course, a new  
distribution module is not trivial, but it's that way for a reason.

> The former is standard fair in languages and the latter can be done  
> independently.
That's a bold claim. Name these languages, so I may ignite your  
strawman.

> 1) Having to recreate the transport every time for every developer  
> is wasteful. Why shouldn't there be a pluggable security model for  
> the transport layer between nodes that would allow standard  
> libraries to be shared?
There should be such a thing. We'd all love it. Your disagreement is  
that it should integrate with the significant toolset that already  
exists. That would be awesome, but it's probably US$250k of programmer  
time to implement and integrate it. That means it will take a while.

> Knowing that the node you are talking with is actually who you  
> believe it is surely useful and would need to be a first step in any  
> further security developments around message passing.
And what of the endpoints inside (pids)? Host-based security doesn't  
have the strongest track record.

> 2) It becomes impossible to utilize the distributed functionality  
> built into the platform. From visualization tools to all the node  
> based libraries. It turns the platform into a husk of what it was  
> IMO. The language is nice as is the concurrency but it also  
> advertises itself as a distributed platform. Well most distributed  
> platforms I've worked with provide more than secret keys to a  
> completely open platform.
Names please.  Not that I don't believe you, but we can't code on  
generalities.

> 3) I'm simply not talking about RPC in some specific case but  
> general sandboxing of the platform. Not leaving holes open that  
> aren't desired. Not allowing any ol' process to communicate with a  
> port. Not allowing anyone to just rpc or spawn os:cmd("rm -rf /").  
> Some features and additions perfectly fit the NIF, Port, Cnode  
> models. Others don't.
I recently added the safe binary_to_term patch. One flag check turned  
10 microseconds into 16. Messaging in Erlang is a fast path for a  
reason. Understand, then, that what seems like reasonable changes  
could very well cut messaging speed in half.

In addition, provisioning a cluster right now is one of the few,  
lightweight deploy tasks that Erlang has. Generating certs is a whole  
new level of trouble.

I'm not saying that security doesn't have value, but the costs of your  
model are:

* slowing down a critical path
* a large time investment
* significant deployment complexity
* significant maintainence load
* a new class of security errors to bite all legacy code
* backwards-incompatible changes to distribution

The port + {packet,4} + binary_to_term method takes approximately 20  
lines of actual code, supervises very well, and funnels quite well  
into a pattern match.

Additionally, almost all security is application-specific. I often  
prefer explicit security (i.e. flowing through a pattern match +  
validation code) than implicity security (in-image messaging  
isolation) precisely because it eases managing the security profile.

-- 
Jayson