July 26, 2012 TC39 Meeting Notes

David Bruant bruant.d at gmail.com
Mon Jul 30 14:06:51 PDT 2012


Le 28/07/2012 15:16, Tom Van Cutsem a écrit :
>
>     > …
>     > Trapping instanceof
>     >
>     > Function [[HasInstance]]
>     >
>     > x instanceof Global answering true if x and Global live in separate
>     > frames/windows
>     >
>     > var fp = Proxy(targetFunction, handler);
>     >
>     > x instanceof fp // handler.hasInstance(targetFunction, x)
>     >
>     >
>     > MM: Explains concerns originally raised on es-discuss list by David
>     > Bruant, but shows the cap-leak is tolerable
>     I'm interested in the demonstration :-)
>
>
> Mark acknowledged your concerns, but pointed out that currently almost 
> no capability-secure JS code is out there that relies on the fact that 
> instanceof doesn't grant access to the LHS. Even so, most of that code 
> will be Caja code, which can be maintained to avoid the leak. In going 
> forward, we can just explain instanceof as an operator that internally 
> sends a message to the RHS, passing the LHS as an argument. In effect, 
> the implicit capability "leak" would become an explicitly stated 
> capability "grant".
Interesting way of viewing the situation. I guess that's fine. Static 
analysis can give all "instanceof" occurences and likely help to easily 
spot unintended grants.


>     > # Proxies and private names
>     > (...)
>     > DH: so name.public === name?
>     >
>     > MM: I like that
>     >
>     > MM: are unique names in?
>     >
>     > DH: I think so
>     If they are, the .public part of private names could be retired
>     with the
>     following setting:
>     * Private names don't trigger proxy traps call and are not be
>     reflectable at all. This is practically equivalent to calling a trap
>     with a useless public counterpart from the caller perspective.
>     From the
>     proxy perspective, since the public part is useless, being called
>     or not
>     sounds like it would be more or less equivalent.
>     * Unique names would be trapped and passed as unchanged as argument to
>     the trap (actually since name.public === name, passing the unique name
>     or its public counterpart is equivalent). If the proxy wants the
>     unique
>     name not to be accessed, it cannot remove it from getOwnPropertyNames
>     trap result. So proxies can emulate their own private names.
>
> We still want proxies to intercept private names. It may be that the 
> proxy handler knows about the private name, in which case it has the 
> "capability" to usefully intercept access to it.
But it may be that the proxy doesn't know the private name for the very 
reason that the name holders do not want any proxy to know it. In that 
situation, why would the proxy trap be called?
The proxy cannot make any constructive use of the public part without 
the private counter part, apart maybe from storing all public names it 
can and wait for a private name leak. Not trapping offers security by 
default.

There is certainly the case of dynamic granting, where you give access 
to the name only later, but I can't think of a practical use case of 
that yet. In any case, if that's what is wanted, it could still be built 
on top of unique names and unintercepted private names.


I see 3 use cases involving names and proxies:
(1) Everyone knows the name, so no need to do anything convoluted to 
hide the name from the proxy. Unique names solve this one elegantly.
(2) By default, no proxy should have access to the name. The current 
proposal has the "trap the public counterpart" design where an attacker 
can wait for a leak; I say that if proxies shouldn't know, they might as 
well not trap at all.
(3) Some proxies can know the name but not some others. That's a 
complicated use case that requires a complicated setting in any case.
The current proposal for this use case requires a mixture of weakmap and 
private names (and their public counterpart). Here my counter-proposal 
needs a mixture of weakmap, private names and unique names which is more 
or less the same thing except maybe that you have to maintain the public 
<-> private mapping yourself in both directions while the current 
proposal gives private -> public for free (you have to maintain the 
other direction yourself anyway).

Like everyone on the list, I have no experience in using proxies and 
private names in code, but I have the feeling that use cases 1 and 2 
cover 80% of the needs (maybe more?), so there is no need to make (2) 
more complicated and potentially less secure.
Whatever the percentage of use case 3 is, it requires a complex setting 
anyway and as I showed, in both cases an equivalent amount of work.

My logic here is: give simple and safe constructs for simple use cases, 
give experts flexible tools to build arbitrarily complex settings.

Is there a disagreement on my analysis?
Is there a benefit in the "public counterpart" design I'm forgetting?

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120730/a609d612/attachment.html>


More information about the es-discuss mailing list