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

[Ulf Wiger]

bile@REDACTED wrote:
> There are several simple,
> noninvasive changes which would provide some amount of sandboxing
> without affecting existing behavior and there has been nothing but
> resistance. 

I don't know about that, but some of the suggestions have actually
affected compatibility, so they haven't actually been non-invasive.

There was actually a pretty ambitious research project on providing
proper sandboxing in Erlang: "Safe Erlang" 
(http://www.unsw.adfa.edu.au/~lpb/research/sserl/). The project
had some good ideas, but eventually didn't result in anything
practically useful.

My EUC06 presentation title "Safe Erlang Reloaded", about Erlhive,
jokingly referred to that research. Erlhive was an attempt to
provide a kind of Erlang sandbox for multiuser Web applications.

Some of the ideas in Erlhive inspired Tony Rogvall to experiment
with quotas in the runtime system. So there have been attempts
to address the security aspects of Erlang, but one should realise
that the acceptance threshold for changes to core parts of Erlang
is pretty high.


> If Erlang is to gain ground as a
> distributed platform it would seem to me that security should be
> addressed. Otherwise its distributedness should take a backseat to it's
> other features as most firms I've ever dealt with simply couldn't allow
> the level of openness it creates.

But Erlang also makes socket communication easier, so building a
distributed system based on user-level TCP-like channes is pretty
straightforward, if you are not willing to suffer the openness
that Distributed Erlang creates. Distributed Erlang was designed
for embedded clusters, where each member of the cluster is
implicitly trusted, and the interconnects are reliable (often
redundant) unencrypted high-speed links.

One of my old projects, CCviewer 
(http://forum.trapexit.org/viewtopic.php?p=30161#30161), a web-based
source code browser, sported a loosely coupled cross-reference
database, where different CCviewer web servers could query each
other for call sites to a given function. The queries were done
using custom Erlang-RPC MIME types, where an MFA was simply
serialized and UUencoded, and unpacked and executed on the other
side. It was trivial to write, and security was in part achieved
by relying on the normal HTTP authentication, and in part by
supporting only the queries understood by CCviewer.

So writing secure distributed apps in Erlang is not that hard.
Retrofitting a sandbox concept onto Erlang is not trivial, and
while it might be possible to achieve slightly better security
with some minor changes, I think it's reasonable to resist that
kind of change until those changes can be shown to be part of
a credible security roadmap, or truly non-invasive and useful
in their own right. Once accepted, features tend to be very
hard to get rid of, even if not formally supported (c.f.
the recent discussions about parameterized modules in Erlang.)

A possible analogy is the record syntax in Erlang, which was
added as a non-invasive change, and which did offer a significant
improvement (although even that has sometimes been questioned)
over the previous situation. The Erlang record syntax has been
heavily criticized through the years, and several alternatives
have been proposed. The OTP team hasn't yet implemented any of
the alternatives, not because they are themselves deeply in love
with the current syntax, or too proud to change, but rather
because they would like to get it right next time.

BR,
Ulf W
-- 
Ulf Wiger
CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
http://www.erlang-solutions.com
---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com