Lecture series on SES and capability-based security by Mark Miller

Jorge jorge at jorgechamorro.com
Fri Nov 4 10:51:30 PDT 2011


On 03/11/2011, at 23:55, Mark S. Miller wrote:
> 3) Although SES is *formally* an object-capability language, i.e., it has all the formal properties required by the object-capability model, it has bad usability properties for writing defensive abstractions, and therefore bad usability properties for use as an object-capability language or for serious software engineering. One example:
> 
> In a SES environment, or, for present purposes, an ES5/strict environment in which all primordial built-in objects are transitively frozen, say Alice uses the following abstraction:
> 
>     function makeTable() {
>       var array = [];
>       return Object.freeze({
>         add: function(v) { array.push(v); },
>         store: function(i, v) { array[i] = v; },
>         get: function(i) { return array[i]; }
>       });
>     }
> 
> Say she uses it to make a "table" instance with three methods: add, store, and get. She gives this instance to Bob. Alice and Bob are mutually suspicious. All of us as programmers, looking at this code, can tell that Alice intended the table abstraction to encapsulate the array. Given just a table instance, can Bob nevertheless obtain direct access to the underlying array?

Yes, this:

function makeTable() {
  var array = [];
  return Object.freeze({
    add: function(v) { array.push(v); },
    store: function(i, v) { array[i] = v; },
    get: function(i) { return array[i]; }
  });
}

o= makeTable();
o.add(1);
o.add(2);
o.add(3);
o.add('Yay!');

o.store('__proto__', {push:function () { console.log(this) }});
o.add();

Gives:

[ 1, 2, 3, 'Yay!' ]
-- 
Jorge.


More information about the es-discuss mailing list