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

Mark S. Miller erights at google.com
Thu Nov 3 15:55:48 PDT 2011

On Thu, Nov 3, 2011 at 2:10 PM, John J Barton
<johnjbarton at johnjbarton.com>wrote:

> On Thu, Nov 3, 2011 at 12:52 PM, Tom Van Cutsem <tomvc.be at gmail.com>
> wrote:
> >. Also, I heartily recommend the talks to
> > those not entirely convinced of the necessity of private/const/frozen
> > features. Mark makes a pretty good case for encapsulation as a necessary
> > building block for ocap-based security
> If I understood Mark correctly, the features needed for SES are
> already part of ES.5 and are shipping in browsers

That is correct. Any browser on which <
http://es-lab.googlecode.com/svn/trunk/src/ses/explicit.html> passes, which
includes Chrome 16, FF Nightly 10, and WebKit Nightly r98831. Opera 12
alpha build 1116 and IE 10 preview 2 both fall short by only one bug that
both teams are aware of and that test262 tests for, so I expect/hope the
release of both will also be adequate.

> (and hence don't bear upon future features).  Did I misunderstand?

These do bear on future features in three ways:

1) Future features could easily destroy all the security gains that ES5
achieved. As an example, for a long time it wasn't clear -- to me at least
-- how "freeze" should affect the ability to mutate hidden own properties,
i.e., own properties named by "private names". The two obvious answers are
a) hidden own properties are treated just like normal own properties --
"freeze" makes them non-configurable and (if data) non-writable
b) hidden own properties are completely exempt from the constraints imposed
by "freeze".
However, both of these answers would decrease rather than increase
security. Further, #b introduces a capability leak, and so would be fatal
for SES. The answer we settled on at the last meeting is
c) hidden own properties that already exist are exempt from "freeze" and
"seal" constraints. However, once an object is non-extensible (whether by
"freeze", "seal", or "preventExtensions"), then new hidden own properties
cannot be added to it.

2) The notorious Ch16 exemptions as stated in ES5.1 <
http://es5.github.com/#x16>, renders all security reasoning necessarily
unsound. For example, an implementation that introduced a non-configurable
ambient method for deleting all the user's files would still be considered
conformant. Going forward, we should make at least <
normative. Beyond this, we need to understand what is the least additional
Ch16 reform needed to enable security reasoning to be sound.

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

If you've already seen this puzzle and know the answer, please don't post.
If no one else has posted the correct answer in 24 hours, I will.

Note that I don't see any realistic way to fix problem #3 in the ES.next
language. My point is only that defensive programming is tricky even after
you've gotten all the formal properties you need. As ES.next introduces
various new abstraction mechanisms, whether classes, enhanced object
literals, proxies, modules, or private names, the design of these can
either help or hurt those attempting to write defensive abstractions. Any
class abstraction that is only useful for making indefensible instances is
worse than useless -- it is actively harmful, both to security and to
serious software engineering.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111103/b8877452/attachment-0001.html>

More information about the es-discuss mailing list