Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

Andreas Rossberg rossberg at google.com
Tue Nov 8 05:26:41 PST 2011


On 3 November 2011 23:55, Mark S. Miller <erights at google.com> wrote:
>> If I understood Mark correctly, the features needed for SES are
>> already part of ES.5 and are shipping in browsers
>>
>> (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.

I'm still trying to grasp the implications of the recent direct proxy
proposal in this respect -- more precisely, its startTrapping
functionality.

It seems to me that the ability to attach to a function, in
particular, invalidates all current security guarantees, since it
gives a whole new way of completely redefining any random function _in
place_ by simply turning it into a function proxy. That is, even if
that function is given by a non-writable binding or property!

To achieve the effect of today's Object.{seal,freeze}, you hence also
would have to make _every_ of the object's properties non-attachable.
That is certainly possible, but seems considerably more fragile. And
it still breaks the security of pre-existing SES code. IOW, I sense a
security hazard.

I also wonder about the effect that turning an (ordinary) object into
a proxy would have on the visibility of private names. If one of the
original methods accesses a private property on `this', then,
according to the private names proposal, the handler only gets to see
the .public property of that name. But can't this still leak
information? The handler cannot use it to _read_ the existing property
data, but it will still receive all future _writes_ to it.

Am I missing something?

/Andreas


More information about the es-discuss mailing list