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