[erlang-questions] Miller's oversight

[Mark S. Miller]

ok wrote:
> This is sadly true.  However, I think it is useful to distinguish  
> between Erlang the language
> and the full Erlang/OTP system.  If you took the language described  
> in the old Erlang book and
> just removed list_to_pid/1 you would have something that was  
> recognisably Erlang and in which
> process IDs were NOT forgeable.  Virtually all Erlang techniques  
> would survive unchanged, and
> the vast majority of Erlang code would be unaffected.

Good. Is there also an easy way to keep normal Erlang code working, but to 
have it use the safe call-though-intermediate-tagging-process pattern 
everywhere it currently uses the unsafe pid-reusing RPC pattern?

In order for distributed Erlang to provide distributed cryptographic 
capability security between mutually suspicious machines, you'll need to 
change the network representation of a pid as well -- to provide 
unguessability and unspoofability, as explained in Chapter 7 of my thesis. 
Currently, does the distributed Erlang protocol use crypto? How does it manage 
keys?


> As a start towards this,
> (a) [...] (b) [...]
> (c) Long term, create a new 'unsafe' module and move all such unsafe  
> BIFs to it.
>      (Burroughs did something very like this in their NEWP language.)

We now have three good papers documenting the issues in deriving an 
object-capability language from an existing memory-safe almost-capability 
language:

"The Oz-E Project:
  Design Guidelines for a Secure Multiparadigm Programming Language"
by Fred Spiessens and Peter Van Roy
at <http://www.info.ucl.ac.be/people/PVR/oze.pdf>.

The Joe-E project, by Adrian Mettler and David Wagner,
at <http://www.cs.berkeley.edu/~daw/joe-e/>.

"How Emily Tamed the Caml"
by Marc Stiegler and myself
at <http://www.hpl.hp.com/techreports/2006/HPL-2006-116.html>.


Experience with all three supports your approach.


> Providing reflection facilities in a language for the sake of  
> debugging (or for any other
> reason) usually seems to result in a language whose encapsulation is  
> more apparent than
> real.  It is for this reason that in Quintus Prolog it is possible  
> (if you work at it) to
> call any predicate in any module.  It is for this reason that  
> Smalltalk, whose encapsulation
> of instance variables appears to be total does in fact let any object  
> change any instance
> variable in any other object (using #instanceVariableAt:put:).


Flat Concurrent Prolog provided virtual meta-interpretive debugging in a way 
that met the needs of security and debugging simultaneously. At 
<http://lists.squeakfoundation.org/pipermail/squeak-e/2003-February/000027.html> 
I speculate on how one might adapt these ideas to Smalltalk and similar 
languages. I call the approach "refraction". Would something like this work 
for Erlang?

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM