Re: Security evaluation of an example DAP policy

On Nov 19, 2009, at 4:00 PM, Marcin Hanclik wrote:

> Hi Adam,
>
> Thanks for your review!
> This is what the BONDI specs need :)
> I am sorry that you are skeptical and believe that with joint forces  
> BONDI and DAP will end up with a good solution.
>
>>> If I understand this policy correctly, this would let a web site
>>> overwrite boot.ini if the user clicks through a prompt-oneshot.   
>>> This
>>> does not seem like a good idea.
> To handle this use case a more general regular expression could be  
> defined.
> E.g. the following would have to be inserted into the prompt-oneshot  
> section
>            <resource-match attr="param:name" func="regexp">/(C|c):\\ 
> (.+)\\(.+)/<resource-match />
> and the following into deny section
>            <resource-match attr="param:name" func="regexp">/(C|c):\\ 
> (.+)/<resource-match />
> Anyway, the BONDI FS is guarded as below.

Allowing write access to *any* file with just a one-shot confirmation  
prompt is unacceptable for the browser context. Or even read access.  
That's why the File API starts with <input type="file"> which has the  
user take an affirmative step to choose a file, rather than confirming  
the Web page's choice of file. This may seem like a subtle issue but  
it makes a huge difference to the security implications.

Access after a blanket prompt to access to read any file, to send  
email as the user, to read or write the contacts list, and to record  
via the camera all sound like extremely risky designs.

Launching an app after a oneshot prompt is also extremely dangerous.  
Combined with other functionality, this can put a Web site one user  
confirmation away from running arbitrary native code.

This is the kind of issue that needs to be considered up-front in the  
design, rather than bolted on by a policy. Many of these issues have  
to be addressed in the API design, not just by tweaking a policy file,  
to be truly Web-safe.

>
>>> You can tell your policy is in trouble because you're blacklisting
>>> C:\WINNT.  What if my system is installed on my D: drive?
> Please note that access to FS is guarded by  
> FileSystemManager.resolve that is described as:
> "Validates and resolves the given location to a File handle and  
> returns a handle. A valid location is prefixed with a valid root or  
> default location and must address an existing and accessible file."
>
> The path is resolved and visible to the JS code, but is it not  
> necessarily readable or writable as is.
> For this there are getDefaultLocations and getRootLocations methods.
>
> In other APIs there are already cases around e.g. "inContacts" that  
> refer to the device-specific information on the policy level.
>
>>> It's emails like this that make me skeptical of the security work
>>> being done in the device APIs working group.
> We try to stay positive and be constructive :)

When a security design seems fundamentally mistaken, I think it's  
important to be really clear about the problems, even if that comes  
off as blunt or harsh to some people.

Regards,
Maciej

Received on Friday, 20 November 2009 00:25:53 UTC