RE: Security evaluation of an example DAP policy

Hi Adam,

I think that
<resource-match attr="param:name" func="regexp">/(C|c):\\(.+)\\(.+)/<resource-match />
should be
<resource-match attr="param:name" func="regexp">/(C|c):\\([^\\]+)\\.+/<resource-match />
up to any further bug in the RE.
Sorry, my problem.

Anyway, the general comment is that the use case is under control based on the current spec.

Thanks,
Marcin
________________________________________
From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Marcin Hanclik [Marcin.Hanclik@access-company.com]
Sent: Friday, November 20, 2009 1:00 AM
To: Adam Barth
Cc: Maciej Stachowiak; Robin Berjon; public-device-apis@w3.org; public-webapps WG
Subject: RE: Security evaluation of an example DAP policy

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.

>>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 :)

Thanks,
Marcin

________________________________________
From: Adam Barth [w3c@adambarth.com]
Sent: Friday, November 20, 2009 12:22 AM
To: Marcin Hanclik
Cc: Maciej Stachowiak; Robin Berjon; public-device-apis@w3.org; public-webapps WG
Subject: Security evaluation of an example DAP policy

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.

You can tell your policy is in trouble because you're blacklisting
C:\WINNT.  What if my system is installed on my D: drive?

It's emails like this that make me skeptical of the security work
being done in the device APIs working group.

Adam


On Thu, Nov 19, 2009 at 1:41 PM, Marcin Hanclik
<Marcin.Hanclik@access-company.com> wrote:
> Hi Maciej,
>
> Thanks for your review!
>
> The page <http://www.w3.org/2009/dap/> does not yet include the BONDI 1.1 Candidate Release at [1].
> The device capabilities [2] could be regarded as a compact form of security considerations within BONDI APIs.
> It should be noted that the device capabilities - although related to BONDI APIs - could be regarded as generic enough to incorporate any APIs.
>
> Based on the BONDI policy format specification, I would propose to start with the following default policy for "the Web":
>
> <policy-set combine="deny-overrides">
>  <policy description="Default Policy for BONDI API & device capabilities within Win2K environment">
>    <target>
>      <subject>
>        <subject-match attr="class" match="website" func="equal"/>
>        <subject-match attr="uri.scheme" match="http" func="equal"/>
>      </subject>
>      <subject>
>        <subject-match attr="class" match="website" func="equal"/>
>        <subject-match attr="uri.scheme" match="https" func="equal"/>
>      </subject>
>    </target>
>    <rule effect="deny">
>      <condition combine="or">
>        <condition combine="and">
>          <condition combine="or">
>            <resource-match attr="device-cap" match="io.file.read"/>
>            <resource-match attr="device-cap" match="io.file.write"/>
>          </condition>
>          <condition combine="or">
>            <resource-match attr="param:name">C:\WINNT<resource-match />
>            <resource-match attr="param:name">C:\Documents and Settings<resource-match />
>          </condition>
>        </condition>
>        <condition combine="or">
>            <resource-match attr="device-cap" match="devicestatus.set"/>
>            <resource-match attr="device-cap" match="commlog.clear"/>
>        </condition>
>      </condition>
>    </rule>
>    <rule effect="prompt-session">
>      <condition combine="or">
>         <resource-match attr="device-cap" match="location.position"/>
>         <resource-match attr="device-cap" match="devicestatus.get"/>
>         <resource-match attr="device-cap" match="devicestatus.list"/>
>        <condition combine="and">
>          <condition combine="or">
>            <resource-match attr="param:inContacts">undefined<resource-match />
>          </condition>
>          <condition combine="or">
>                <resource-match attr='device-cap' match='messaging.email.send'>
>                <resource-match attr='device-cap' match='messaging.mms.send'>
>                <resource-match attr='device-cap' match='messaging.sms.send'>
>                <resource-match attr='device-cap' match='messaging.binary.send'>
>          </condition>
>        </condition>
>      </condition>
>    </rule>
>    <rule effect="prompt-oneshot">
>      <condition combine="or">
>         <resource-match attr="device-cap" match="applauncher.launch"/>
>         <resource-match attr="device-cap" match="io.file.write"/>
>      </condition>
>    </rule>
>    <rule effect="permit">
>      <condition combine="or">
>        <resource-match attr='device-cap' match='appconfig.get'>
>      </condition>
>    </rule>
>    <rule effect="prompt-blanket">
>      <condition combine="or">
>        <resource-match attr="device-cap" match="appconfig.set">
>        <resource-match attr="device-cap" match="applauncher.get">
>        <resource-match attr="device-cap" match="camera.access">
>        <resource-match attr="device-cap" match="camera.capture">
>        <resource-match attr="device-cap" match="camera.record">
>        <resource-match attr="device-cap" match="commlog.sms.get">
>        <resource-match attr="device-cap" match="commlog.mms.get">
>        <resource-match attr="device-cap" match="commlog.email.get">
>        <resource-match attr="device-cap" match="commlog.call.get">
>        <resource-match attr="device-cap" match="io.file.read"/>
>        <resource-match attr="device-cap" match="location.position">
>        <resource-match attr="device-cap" match="messaging.email.attach">
>        <resource-match attr="device-cap" match="messaging.mms.attach">
>        <resource-match attr="device-cap" match="messaging.email.getAccounts">
>        <resource-match attr="device-cap" match="messaging.email.send">
>        <resource-match attr="device-cap" match="messaging.mms.send">
>        <resource-match attr="device-cap" match="messaging.sms.send">
>        <resource-match attr="device-cap" match="messaging.binary.send">
>        <resource-match attr="device-cap" match="messaging.mms.subscribe">
>        <resource-match attr="device-cap" match="messaging.sms.subscribe">
>        <resource-match attr="device-cap" match="messaging.binary.subscribe">
>        <resource-match attr="device-cap" match="pim.contact.read">
>        <resource-match attr="device-cap" match="pim.contact.write">
>        <resource-match attr="device-cap" match="pim.task.read">
>        <resource-match attr="device-cap" match="pim.task.read">
>        <resource-match attr="device-cap" match="pim.event.write">
>        <resource-match attr="device-cap" match="pim.event.read">
>        <resource-match attr="device-cap" match="ui">
>      </condition>
>    </rule>
>  </policy>
> </policy-set>
>
>
> Thanks,
> Marcin
>
> [1] http://bondi.omtp.org/1.1/CR/
> [2] http://bondi.omtp.org/1.1/CR/apis/devcaps.html
> ________________________________________
> From: public-device-apis-request@w3.org [public-device-apis-request@w3.org] On Behalf Of Maciej Stachowiak [mjs@apple.com]
> Sent: Thursday, November 19, 2009 6:35 PM
> To: Adam Barth
> Cc: Robin Berjon; public-device-apis@w3.org; public-webapps WG
> Subject: Re: Trying to summarise (was Re: DAP and security)
>
> On Nov 19, 2009, at 7:58 AM, Adam Barth wrote:
>
>> On Thu, Nov 19, 2009 at 3:24 AM, Robin Berjon <robin@berjon.com>
>> wrote:
>>> Finally, we can all talk about policy and trust in browsers until
>>> we're bluer in the face than a hypothermic smurf the fact of the
>>> matter is that I don't believe that this is a case where discussion
>>> can produce consensus. There are use cases for policy, and
>>> solutions for those will be developed at the very least for the
>>> widgets landscape. If it so happens that they yield interesting
>>> innovative stuff that could be useful in browsers, then it'll be
>>> easy to point to it as proof and demo. Far easier than to argue
>>> about it, and it'll happen faster if we create the technology
>>> rather than talk about it :)
>>
>> I don't believe you can design secure APIs by first implementing the
>> APIs and then worrying about security later.  That's the road that
>> leads to systems like User Account Control (UAC).  Instead, you need
>> to understand the security requirements up-front and design your APIs
>> to match.
>>
>> If you ignore input from browser vendors who've been working with
>> these issues for years, it's unlikely you'd design something they'll
>> find palatable.
>
> This is pretty much how I feel about the security design aspects of
> many of the proposed DAP specifications. If you look at the specs
> listed in the Input section here: <http://www.w3.org/2009/dap/>, they
> mostly have missing or unhelpful Security Considerations sections. The
> BONDI security document listed there doesn't seem to provide anything
> for security other than a policy mechanism, with no hint of what might
> be a safe default policy for the Web.
>
> Apple will consider joining the DAP Working Group, but the security
> direction so far is on reason we are hesitant.
>
> Regards,
> Maciej
>
>
>
> ________________________________________
>
> Access Systems Germany GmbH
> Essener Strasse 5  |  D-46047 Oberhausen
> HRB 13548 Amtsgericht Duisburg
> Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
>
> www.access-company.com
>
> CONFIDENTIALITY NOTICE
> This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
> individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
> If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
>

________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.


________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Friday, 20 November 2009 00:11:34 UTC