Security Demands Simplicity (was: Private Slots)

David Bruant bruant.d at gmail.com
Mon Jan 21 00:04:53 PST 2013


Le 21/01/2013 03:35, Allen Wirfs-Brock a écrit :
>
> On Jan 20, 2013, at 5:42 PM, David Bruant wrote:
>
>> Le 20/01/2013 23:05, Allen Wirfs-Brock a écrit :
>>
>>
>>> On Jan 20, 2013, at 11:12 AM, David Bruant wrote:
>>>> "complicated" was an expression. Either proxies don't work with 
>>>> class instances, making them vastly pointless or classes need to 
>>>> publicize their private symbols (or maybe expose something like 
>>>> "myClass.acceptProxy" which is marginally better), thus ruining 
>>>> their own encapsulation.
>>> Actually this whole discussion makes me question the validity of the 
>>> current Proxy design rather than that of private Symbol.  I may be 
>>> on the road towards getting on the NotificationProxy train.
>> If there is time to make that big of a change, Mark's idea of action 
>> proxies could be considered too. I've only expressed reluctance on 
>> the list, because it allows to do weird things when badly used, but 
>> for all use cases I've had, it would be fine. Tom expressed 
>> reluctance regarding the cost of action proxies, but I'm not entirely 
>> sure it's founded.
>> Although Notification and action proxies are good to get rid of the 
>> invariants cost, I'm not entirely sure they can help to reduce the 
>> complexity when it comes to private symbols.
>>
>>
>>> (...)
>>>
>>> This suggests a possible generalized solution to the Proxy/private 
>>> symbol exposure problem:
>>>
>>> The [[Get]] and [[Set]]  (and probably some others) internal methods 
>>> of a proxy never call the corresponding trap when the property key 
>>> is a private Symbol.  Instead, they trace the [[Target]] chain of 
>>> the proxy until a non-proxy object is reached (call this the 
>>> "ultimate target").  It then invokes the ultimate target's 
>>> [[Gett]]/[[Set]] using that same private Symbol key.  The result of 
>>> that operation is then returned as the value of the original 
>>> [[Get]]/[[Set]].
>>>
>>> The "private" state access is applied to the correct object and 
>>> there is no exposure of the private symbol!
>> It can work for built-in private state (and could work for private 
>> class syntax too), but not for user-generated or obtained private 
>> symbols:
>> Let's say 2 untrusted parties are in 2 membranes. They share a 
>> private symbol and each has access to a proxy wrapping a common 
>> target. With the private symbols semantics you're describing, these 2 
>> untrusted parties have an unmediated communication channel.
>
> How did they originally come to share the private symbol?  Don't they 
> have to have some common point of origin with visibility of the symbol 
> or have both been provided the private symbol by some third party.
No, they have shared the symbol through mediated communication. As Tom 
has argued multiple times, while symbols are "objects", they should be 
considered as primitive values that can't be wrapped by proxies.
So the 2 parties, while using the mediated communication came to share a 
private symbol. They didn't need a third party for that.

> In either case couldn't they have closure captured references to each 
> other and use those references for direct communicate?
No, you created each of this context separately and you are the only 
entity with access to both and for whatever good reason of yours, you 
initially make them share a single object through which their mediated 
communication start. A setup like one that Mark describes much better 
than I do [1].
For instance, you're a webpage, each untrusted party is a widget and you 
have an event mechanism through which you allow widgets to communicate 
for some time and for whatever good reason.

>> An unmediated communication channel defeats the purpose of having put 
>> the 2 untrusted parties in membranes in the first place.
>> The semantics of user-generated or obtained symbols has to go through 
>> proxy mediation because of this use case, hence the whitelist and the 
>> unknownPrivateSymbol trap in the current proxy design.
>
> This really makes me start to question even more the viability of 
> Proxy based membranes (direct proxies, at least) as an isolation 
> mechanism. Independent of private Symbols,  it isn't clear that it is 
> a practical approach.
I wonder how you're coming to such a question. It is a practical 
approach assuming proxies can properly mediate communication.

> Also, I think some of the issues discussed in the thread 
> https://mail.mozilla.org/pipermail/es-discuss/2012-December/027246.html have 
> bearing on this discussion.  It is probably worth taking a second look.
I think too that this thread revealed unclear stratification properties 
in built-in algorithms, but I'm not following how relates to this 
discussion.

David

[1] 
http://www.youtube.com/watch?v=w9hHHvhZ_HY&feature=player_detailpage#t=2574s 

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


More information about the es-discuss mailing list