Re: Simple approach for <access>

On 19 Apr 2009, at 16:24, Robin Berjon wrote:

> On Apr 16, 2009, at 17:23 , Thomas Roessler wrote:
>> 1. How is the information in this access element going to be used  
>> at installation time or distribution time?  I'd like to see some  
>> spec text that explains this.

> My understanding is that this is like the feature element and  
> others: it is metadata and its enforcement depends on a security  
> policy. When that security policy intervenes (I would expect at  
> runtime, for every access) is presumably orthogonal.

The security policy is likely to intervene at two different times:

1. Install time, when it might turn into a request to the user to  
grant the requisite privileges.

2. Run time, when it will at the very least be enforced.  (Or might  
cause user interactions...)

>> 2. If one of the risks we're interested in is firewall traversal,  
>> then then proposed domain name wildcard has a somewhat different  
>> risk profile than just a single domain name:  while you can do a  
>> DNS rebinding attack for a single hostname, that's a well-known  
>> issue, and hopefully worked around in today's browser engines.   
>> With the wildcard, though, it becomes relatively easy to do  
>> firewall traversal:  For example, one could simply generate DNS  
>> records n.n.n.n.example.com that point to the IP address n.n.n.n.

> I think that this is also meant to be orthogonal to firewalls, but  
> maybe I'm missing something?

Of course it's orthogonal to firewalls.  However, it's not orthogonal  
to looking at the side effects that the design here might have on  
deployments.

If a particular design for the <access/> element is likely to cause a  
larger attack surface, then that's a consideration that needs to go  
into the design of <access/>.  I'm claiming that the implicit  
subdomain model has that effect.

Received on Monday, 20 April 2009 09:29:37 UTC