Searching for Erlang Security topics you necessarily find the work done by Lawrie Brown, Dan Sahlins and others in the late 90’s, and their proposed changes to the Erlang implementation. This work was to some extent parallel and closely related to academic research by Gustaf Naeser, Rickard Green and Bertil Karlsson on the SafeErlang project line. Despite the number of documents covering this work, extending between 1996 and 2000, I have been unable to determine exactly the level of cooperation between the authors, although it is evident that Dan Sahlin had a prominent role in both lines of work (in cooperation with Lawrie Brown in one case and as supervisor of research work in Sweden in the other). In the late 90’s Sahlin had other areas of research related to Erlang, for example this: http://www.erlang.se/publications/dan96.pdf. He worked for Eriksson until 2002.
The main publications detailing the “safe” Erlang initiatives are (as far as I have been able to verify) the following:
– “Mobile Code Security,” by Lawrie Brown, AUUG 96 and Asia-Pacific WWW 2nd Joint Conference, September 1996. http://www.unsw.adfa.edu.au/~lpb/papers/mcode96.html.
– “Your First Introduction to SafeErlang,” by Gustav Naeser , Uppsala University, January 1997 http://www.csd.uu.se/~gaffe/general/safe/nae97a.ps.gz. (link invalid!)
– “Introducing SERCs Safer Erlang,” by Lawrie Brown, Australian Defence Force Academy, April 1997 http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/ssp97/sserl97a.html
– “Towards a Safer Erlang,” by Lawrie Brown, Australian Defence Force Academy, June 1997 http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/ssp97/sserl97c.html
– “Custom Safety Policies in SSErl,” by Lawrie Brown, Australian Defence Force Academy, Technical Note, June 1997. http://www.unsw.adfa.edu.au/~lpb/papers/ssp97/sserl97e.html.
– “SafeErlang,” by Gustaf Naeser – Master Thesis – Computing Science Department, Uppsala University, June 9th 1997 (Supervisor: Dan Sahlin) http://www.erlang.se/publications/xjobb/0109-naeser.pdf
– “SSErl – Prototype of a Safer Erlang,” by Lawrie Brown, School of Computer Science, Australian Defence Force Academy, October 1997 – http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/tr9704.html
– “Extending Erlang for Safe Mobile Code Execution,” by Lawrie Brown, Australian Defence Force Academy, Technical Report, No CS03/97, Nov 1997. http://www.unsw.adfa.edu.au/~lpb/papers/tr9703.ps.gz
– “Extending Erlang for Safe Mobile Code Execution,” by Lawrie Brown (School of Computer Science, Australian Defence Force Academy) and Dan Sahlin (Ericsson AB), May 25, 1999) http://seit.unsw.adfa.edu.au/staff/sites/lpb/research/sserl/icics99.html
– “Secure Distributed Communication in SafeErlang,” by Bertil Karlsson – Master Thesis – Department of Teleinformatics, The Royal Institute of Technology October 10th 2000 (Supervisor: Dan Sahlin – Ericsson AB) http://www.student.nada.kth.se/~d95-bka/thesis.html
– “Enhancing Security in Distributed Erlang by Integrating Access Control – Approaching a Real SafeErlang Implementation,” by Rickard Green, The Royal Institute of Technology, June 27, 2ooo (Supervisor: Dan Sahlin – Ericsson AB) http://www.erlang.se/publications/xjobb/d95-rgr.thesis.2s.pdf
Lawrie Brown described his work as follows:
“I identified a need for extensions to support a hierarchy of nodes within an Erlang system to provide a “custom context”, restrictions on “side-effects”, and resource limits for processes executing in each node; the use of capabilities for nodes, processes, ports, and user defined references, to provide a finer granularity of control on the use of these identifiers; and support for remote module loading mechanisms that preserve the context for such modules. Following the initial design and prototype phase, I developed some ideas on the best methods for specifying and implementing safety policies in this environment.“ (See: http://seit.unsw.adfa.edu.au/staff/sites/lpb/research/sserl/ )
Despite the continuity of research and the detailed approach towards a “safer” Erlang, though, I cannot find any reference that indicates that any part of this work was adopted by the Erlang engineering teams, although I cannot exclude that it was discussed. Some evidence of discussion of modifications to the Erlang core exist in the Erlang Questions mailing list (http://erlang.2086793.n4.nabble.com/Erlang-Questions-f2086794.html ) Searching for “a less trusting Erlang” produces a long exchange between Erlang users and some Erlang team members and the works listed above are mentioned with interest. This conversation ended without any indication that SafeErlang or any of the proposals around it had been accepted by the Erlang development teams.
Symptomatic of the different perspectives during the discussion is a message by an OTP engineer (K. Lundin, Eriksson) who wrote: “We have not been able to prioritize work towards “SAFER” built in distribution mechanisms since the current implementation support local trusted networks well enough and that was the intended use from the beginning. This kind of distribution is still the dominating. It might however be the right time to do something in this area now.” (13th October, 2009)
Other participants offered solutions by suggesting the use of SSL-protected connections, and there was also a discussion focused on the Security implications of cross-node messaging. Among other participants, Ulf Wiger wrote this regarding “turning off” the remote procedure service: “The one way I know of to torn it off is to start Erlang with erl –mode minimal. Not really sure where –mode minimal is documented, though, but rpc is not all it turns off – you get no Distributed Erlang at all. So I don’t think that solves your problem. You should see this as an example of how difficult it is to make Erlang safe if you allow remote processes to send messages. Since any message can be sent to any process, ‘rex’ [the rpc server] is just the most obvious vulnerability to exploit. You are much better off setting up a narrow pipe and allowing only a small set of messages. Since most communication is wrapped inside function calls, it really isn’t as limiting as you might suspect at first.” (October 14th, 2009)
It is difficult to comment this conversation fully, and I mention it here only for reference, because it shows that the different teams were aware of the issues around Security and that there was a discussion. The more important point is that the approach suggested by Sahlin, Brown and others was not followed. Because there was *no other* integrated, Security-focused attempt at enhancing Erlang (as far as I know) the implicit rejection of the SafeErlang and SSErl approaches is very important to understand the ethos and orientation of the Erlang designers and product managers.
Other approaches, reflected in an earlier suggestion by M.Fig (through Erlang Questions ) for the integration of Erlang with the E language also failed. (See: http://erlang.2086793.n4.nabble.com/Proposal-E-Erlang-integration-td2089481.html#a2089482). It is important to note here that both proposals (SafeErlang/SSErl and the so-called E-Erlang integration) involved introducing the concept of “object-capabilities” or “security capabilities” to enhance the core Erlang language from the bottom up. In other words, the proposals rejected were focused on “language security” whereas the Erlang team favoured (as far as I can see) external or third-party approaches to the security of Erlang solutions.
The first paper using the name SafeErlang seems to be Naeser’s “Your First Introduction to SafeErlang” (January 1997); and this was closely followed by “Custom Security Policies in SSErl” and “Introducing SERCs Safer Erlang (by L. Brown, both dated in April 1997). From the beginning of this work, the emphasis on Security principles is very prominent. Lawrie writes:
“The Erlang language provides a number of inherent benefits. Its dynamic typing and single assignment prevent many classes of errors. The main additions involve controlling access to resources used to create and communicate with other processes, and to external devices. Currently this is through the use of Pids and Ports, with few restrictions on their use. Also, there is a need to partition a single “hardware” Erlang node into a number of subnodes, each with a custom view of the world (in terms of registered names and which modules are available and used).” (See: http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/ssp97/sserl97a.html
“I propose protecting the former (Pids and Ports), as well as Nodes, by making them password capabilities. In a password capability system, the capability is a data item which indicates the entity owning it (a node in this case), and a random value (selected sparsely from a large address space). An appropriate capability must be supplied, explicitly or implicitly, in order to perform most “unsafe” operations (which in Erlang involve the use of Built-in Functions – BIFs). The user is free to try and forge a capability, but it is statistically highly improbable that they’ll create a valid one. The capability has no meaning on its own, but is only of use when supplied to its owner (a node) along with a request for some operation. One advantage of password capabilities is the ease of revocation, by removing it from its owning entity’s list of currently valid capabilities. Any process subsequently trying to use it will fail with an invalid_capability (as also occurs if a forged capability is used).” (See:http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/ssp97/sserl97a.html)
“For the latter, I propose creating a concept of subnodes to provide custom views. Each subnode should provide a “context” for processes executing in it. It provides distinct “registered names” and “module alias” tables. The registered names can be modified by processes with an appropriate subnode capability, and is used to send messages to named servers. The “module alias” table is specified when the node is created, and is used to alias module names at run-time when functions are invoked. By appropriate customisation, modules executing within a subnode can be provided with a custom view of modules used and servers available.” (See:http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/ssp97/sserl97a.html)
In a different paper, Brown continues with his proposal:
“SERCs Safer Erlang (SSErl) is a prototypical implementation of what I believe to be a simpler and more comprehensive design of a secure Erlang execution environment. It is currently implemented as a collection of glue functions substituted by a modified Erlang compiler for all calls of “unsafe” BIFs. These interact with “node” server processes, one for each distinct (sub)node on the Erlang system. The prototype supports capabilities for pids, ports, and nodes; and a hierarchy of subnodes on each Erlang system[…]” (See: http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/ssp97/sserl97b.html )
In the same document, Brown comments on the “prior work” done by G. Naeser:
“SafeErlang incorporates three new concepts. Encrypted capabilities are used for pids and nodes, but not (yet) for open_port. This seriously limits its ability to protect key standard library routines, and accesses to external resources. Also the use of encryption introduces problems with appropriate key distribution in distributed environments, along with the selection of appropriate cryptographic algorithms. Subnodes are used to provide a custom collection of modules (with names rewritten at compile time), and to provide resource limits on processes executing in the subnode. Lastly, a new module loading (mid) mechanism is supplied to support code mobility. A new “code” server is used to manage the code (mid) distribution as required. In their current system, this necessitates a recompilation of source every time the module is loaded (in part to cope with varying module names needed, depending on which subnode it is being loaded in to).“ (See: http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/ssp97/sserl97a.html)
According to the notes found in Lawrie Brown’s website (Link: http://seit.unsw.adfa.edu.au/staff/sites/lpb/papers/ssp97/ ) these papers were superseded by joint work with D. Sahlin and his own paper titles SSErl –Prototype of a Safer Erlang 1997) (See: http://seit.unsw.adfa.edu.au/staff/sites/lpb/research/sserl/icics99.html).
I am quoting L. Brown’s contributions both alone and working with Sahlin, because, although Gustaf Naeser’s work is the first reference to this line of work, the quoted materials contain the most complete rationale and explanation of how an object-capability approach could transform Erlang into a Secure language. Naeser’s work remains a key reference though as it clearly identifies the weakness of the Erlang “system” and the fact that these weaknesses mean that processes become threats for other processes. The key solution proposed by Naeser is still essentially the fundamental one: “making the [process] identifies used to access objects more secure” (Page 22 of Naeser’s thesis).
Following the same path, and under the supervision of Dan Sahlin, both Rickard Green and Bertil Karlsson complemented Naeser’s work by detailing the object-capability approach. R. Green explains the history of the SafeErlang project as follows:
“The idea to extend Erlang with security mechanisms was brought up by Dan Sahlin and Gustaf Naeser. This was during Gustaf Naeser’s master’s thesis work in 1996, at Computer Science Laboratory at Ericsson Utvecklings AB, with Dan Sahlin as supervisor. They examined how Erlang would have to be modified to support mobile agents operating on Erlang systems.” (Page 1 of Green’s thesis).
Green works out how the access controls could be implemented in terms of access to processes, external resources, the run time system itself and data. The thesis though is focused on access control only and both the implementation of sub-nodes and remote code security are left aside.
In the same year, Bertil Karlsson’s thesis addressed the communication side of a more secure Erlang by developing concepts of encryption of inter-process messaging. Karlsson has a very good summary of the work done by the various strands of the SafeErlang initiatives in a table on page 31. There we see that the initial work by Naeser, Sahlin and Lawrie focused on Security solutions for the following areas:
– Memory consumption
– Number of processes
– Access controls
– Remote code loading
– Secure environments for untrusted code
His own work and that of Green were focused on secure communications and strong authentication. Taken together, the papers and technical prototypes created by these authors cover all the key areas that are *still* open if one were to consider how to enhance Erlang security capabilities.
Although Lawrie worked with a view towards mobile agents, the approach he proposed together with Sahlin is valid for any Erlang environment. In “Towards a Safer Erlang,” Lawrie says:
“The consensus on the extensions needed to control side-effects is that two changes are needed to the current Erlang system:
Nodes should form a hierarchy within an Erlang system to provide a custom “context” to services available, restrict the use of code with side-effects, and impose resource utilisation limits.
Capabilities used to impose a finer granularity of control on the use of process (and port and node) identifiers, making these unforgeable with a specified set of rights on their use.”
Lawrie and Brown write in their joint paper titled “Extending Erlang for Safe Mobile Code Execution” (May 25 1999) the following:
“In his taxonomy of issues related to distributed hypermedia applications, Connolly in particular distinguishes between Run-time Safety—which is concerned with whether the runtime system will guarantee that the program will behave according to its source code (or abort) ; and System Safety—which is concerned with whether it is possible to control access to resources by a piece of executing code.” (Page 1)
While I object to the use of the term “safety” in this context and prefer the term Security, in any case we have here a very productive differentiation. Indeed, in my research on Erlang Security I am looking for System Security and not for run-time security. By this I mean fine-grained security focused on process and user access and execution controls. For this reason I have emphasised the qualitative aspects of the language and how Erlang does not reflect Security concerns nor principles.
Lawrie and Sahlin had the same concern when they wrote:
“In Erlang, a process is a key concept. Most realistic applications involve the use of many processes. A process is referred to by its process identifier (pid), which can be used on any node in a distributed Erlang system. Given a pid, other processes can send messages to it, send signals to it (including killing it), or examine its process dictionary, amongst other operations. Erlang regards external resources (devices, files, other executing programs, network connections, etc.) also as processes (albeit with certain restrictions, in much the same way that Unix regards devices as a special sort of file). These processes are called ports and are referred to by their port number, which is used like a pid to access and manipulate the resource.” (Page 4)
This can be addressed only by “low-level” or –more precisely– “language-orientated” Security capabilities which allow the programmer to express the necessary controls on processes and ports.
The authors continue:
“In standard Erlang a pid or port identifies used to access processes or external resources is both forgeable and too powerful. […]Another limitation of the current Erlang system from a safety perspective is the fact that a given Erlang system (that is, one instance of the run-time environment) forms a single node. All its processes have the same privileges and the same access to all resources (file system, modules, window manager, devices) managed by the system. There is no mechanism to partition access within a system, so that it may be mediated via a trusted server process.” (Page 5)
A definition of a Security capability is provided, although perhaps too close to the typical Erlang approach (i.e. “process” instead of “objects” or “actors” as the “units of computation”:
“We define a capability as a globally unique (in time and space), unforgeable name for (a specific instance of) some resource, and a list of rights for operations permitted on the resource by holders of the capability. We use such capabilities to replace the existing forgeable, unconstrained identifier for nodes, ports, processes, etc.” (Page 6)
There are many essential aspects of the Lawrie-Sahlin approach in this paper, as for example the types of capabilities proposed (encrypted-hashed and password-based), or the way in which a hierarchy of nodes provides custom context for code execution. Now, despite the richness of this and other quoted materials, I think that only the essence of the effort has to be retained, i.e. the fundamental aspects of this approach, which are applicable to any programming language and any system. It other words, it is not my intention to propose again a capability-based enhancement of Erlang (although I confess that for a while I thought that this could be productive).
Instead, while continuing with my research on the Security-related aspects of Erlang-OTP, I will investigate separately how to develop a Language-Orientated approach to Security, knowing that the Erlang community already passed the opportunity to follow this way. There may have been good or bad reasons for the path taken, and I am not a good judge in terms of what would have been more convenient for the development of Erlang technologies. I guess that “product management” decisions were decisive for the way Erlang evolved maintaining a high level of indifference towards Security concerns.
I will limit my self to say that –in terms of Security– the concerned Solution Architects and Security Professionals need to set their hearts and minds somewhere else.