WebAPI Security Discussion: Device Storage API

[Paul Theriault]

Please reply-to dev-w...@lists.mozilla.org

Name of API: Device Storage
Reference: https://wiki.mozilla.org/WebAPI/DeviceStorageAPI

Brief purpose of API: Let content access files based on name and type.
Can be enumerated.

Inherent threats: Use excessive resources (file space), read files,
change or delete files. Files could potentially contain confidential
information.
Threat severity: high to critical - privacy concerns, loss of user data,
access to confidential data.

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: Access a previously taken profile
picture, select a song to play.
Authorization model for uninstalled web content: Explicit (OS Mediated)
Authorization model for installed web content: Explicit (OS Mediated)
Potential mitigations: Make sure the user knows what files is being
accessed when asking permission. No option to remember permission. OS
mediated interface (like file picker - via intents?).

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Photo gallery
Authorization model:
Implicit: Create (e.g. camera saving a photo to the camera roll)
Explicit: Read, Modify (delete,rename,overwrite,edit)
Potential mitigations: Granting permission only for a particular type of
file (images, pdf, etc).

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: File manager
Authorization model: Implicit
Potential mitigations:

Notes: Permission should be given on a type basis. So giving
permission to access music doesn't automatically give permission to
photos. If the type is a string literal when the code is reviewed, that
would mitigate the issue. Otherwise sub-permissions for types
(device-storage.music) or separate permissions for each type
(device-storage-music) would be needed. Also has the benefit that it
allows the permission prompt to be more explicit about what is being
granted.

[pther...@mozilla.com]

(Final call for feedback - Please reply-to dev-w...@lists.mozilla.org.)


I'd like to finalize the permissions model for this API, but there hasn't been any feedback here, and I am not confident original proposal is effective or accurate. The problem I see with the proposal below is that it doesn't address the threat of existing files being deleted/modified (see https://wiki.mozilla.org/WebAPI/DeviceStorageAPI for more discussion).

Does anyone have thoughts on the following questions:
- Will there be separate shared file stores (e.g Photos, music, videos I assume yes, maybe this is a b2g specific thing though?)
- Will access in some cases be only granted to one specific file store (I am thinking here to support a prompt like "Do you want to grant access to this app to read your photos"
- Will create/read be a separate permission to edit/delete (I think it should be, or there should be some way to prevent untrusted or even trusted apps from deleting all your media)

- Paul

[Doug Turner]

> Does anyone have thoughts on the following questions:
> - Will there be separate shared file stores (e.g Photos, music, videos I assume yes, maybe this is a b2g specific thing though?)

yes.

> - Will access in some cases be only granted to one specific file store (I am thinking here to support a prompt like "Do you want to grant access to this app to read your photos"

not initially. that could be done in the future.

> - Will create/read be a separate permission to edit/delete (I think it should be, or there should be some way to prevent untrusted or even trusted apps from deleting all your media)

no. access is either allowed or not.

[Doug Turner]

> Does anyone have thoughts on the following questions:
> - Will there be separate shared file stores (e.g Photos, music, videos I assume yes, maybe this is a b2g specific thing though?)

yes.

> - Will access in some cases be only granted to one specific file store (I am thinking here to support a prompt like "Do you want to grant access to this app to read your photos"

not initially. that could be done in the future.

> - Will create/read be a separate permission to edit/delete (I think it should be, or there should be some way to prevent untrusted or even trusted apps from deleting all your media)