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.
>

Received on Thursday, 19 November 2009 23:23:47 UTC