Erlang Security: what is the matter?

What is it with Security objectives that we so frequently find them missing in Software design and development? Granted that not every software project should or must address security capabilities, it nevertheless seems interesting to point out the discontinuity that seems to exist between these disciplines.

People who are active in either of these areas will confirm that in any “normal” context Security *does* occupy a secondary place in the planning and attention of the software design and development effort, and when it does not, it becomes circumscribed to elementary aspects, for example the establishment of file access permissions.

While reading Erlang related materials I am trying to compile all that is relevant to Security. My goal is to ascertain not only that Erlang and Erlang-based applications can be “made secure” by the implementation of standard security recipes from the space of application development, but also if this particular language offers any advantages in terms of Security in general. By “in general” I mean Security principles that are not limited to “web security” (for example for a web server), or “messaging security” (for example for a messaging engine).

These standard aspects will be covered as part of the study of Erlang, but the focus overall will be on understanding how Erlang can support the perspectives of direction, selection, protection and verification for any software project. In this (following the model I describe in other parts of this website) I do not limit the scope of security to “protection” of informational assets, and aim at covering all areas of the decision process and the “modalities” in which Security is served (see: ).

It is a tall order for any programming language now (with the exception of those explicitly designed to support Security like  “Joule”, “E” and other capability-centric constructs) to be able to satisfy and comply with the wider sense in which we are talking about Security here. In one sense, addressing the four perspectives of Security is currently not part of the drivers of the Software Industry, so we cannot expect that the programming languages used in this space and the projects they give raise to are in any way Security-complete.

On the other hand, though, we do expect that programming languages and their implementers at least follow the conventional targets, i.e. the commonly accepted definition of what Security is. In this sense, we also expect that a modicum of security is included or implied in any Software project despite the engineering drivers and the self-imposed limitations that may exist.

A negative although perhaps explainable example can be seen in one of the few studies that exist focused on the development of an embedded Erlang system. (See “Development of an Erlang System Adapted to Embedded devices” by F. Andersson and F. Bergström, Institutuionen för Informationsteknologi, June 2011). To be fair to the authors, they define the limitations of their study very clearly and properly, centred on engineering drivers. These are focused on obtaining a reduced Erlang platform, with small memory and storage footprint, capable of being deployed on (small) embedded systems.

Anderssson and Bergström’s work is definitely interesting in that it describes a way to reduce the Erlang virtual machine and libraries to a size which can be implementable in recent circuit boards. It also offers useful measurements regarding memory consumption and performance. In any case, due to the rarity of this kind of assessment, the paper discussed here should be a reference for further work towards improved embedded Erlang implementations.

On the other hand, when looked from the Security Perspectives, the work raises several questions which at some point need to be addressed to the whole of the Erlang community and beyond that to the Software Industry as a whole: where and how is Security represented in the design?

In the case of the Andersson  & Bergström paper, not only are Security objectives absent from the prospect of their study, but we can say also that Security mechanisms become overridden due to decisions made during the design of the implementation. Critically, near the end of the paper (p.25 the authors inform us that “[w]e successfully passed the whole test suite except for the test that try to manipulate file permissions […] We failed to pass the file permission tests since the file system being used on the SD cards (FAT32) did not support changing permissions…”.

While it can be understood (as indicated before) that engineering and scope decisions have to constrain the test conditions, this small detail becomes a prefiguration, a symbol of the type of problems the IT industry faces every day: which capabilities are discarded, not tested or not even sought in the context of our work?

Andersson and Bergström also report that their test environment failed those tests that “allocate a lot of memory.” While not so clearly a failure from the point of view of Security, it is evidently an area that has to be considered more carefully, as memory allocation and deliberate memory overflows are relevant aspects of secure design.

So, while the authors demonstrate that “getting Erlang up and running on the boards” (the supporting circuitry) “was easier than what we expected it to be,” it is my understanding that no Security functionality or capability was considered or tested and hence the performance and memory consumption results need to be put in perspective until a better approach is found.

Here I reiterate my view that the commented study is useful and illustrative of the very good qualities found in Erlang-OTP, but it does not help us to see if this special language is different from the others in respect to the often-ignored Security perspectives.

(Reference: F. Andersson, F. Bergström “Development of an Erlang System Adapted to Embedded Devices, June 2011 – )