Security/AppsProject/B2GDeviceStorage
Item Reviewed
{{#set:SecReview name=B2G Device Storage |SecReview target=https://wiki.mozilla.org/WebAPI/DeviceStorageAPI https://bugzilla.mozilla.org/show_bug.cgi?id=744542 https://bugzilla.mozilla.org/show_bug.cgi?id=717103 Permission dicussion: https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapps/m14_VeosQvg }}
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- allows content to create/edit/delete files from known locations (define: known locations?)
- use case: give me all the pictures
- hashtable of arrays of files
- mac (~/pictures )
- phone (/data/pictures or /sdcard/DCIM)
- Only is exposed to all certified and trusted Apps not content
- the permission must be specified in the manifest
- Returns array of DeviceStorage objects
- currently access is all or nothing
- proposed to seperate access by permssions (seperate read and create/edit/delete permissions)
- proposed to seperate access by file repository (seperate permissions per repository, or even their own repository)
What solutions/approaches were considered other than the proposed solution?
`
Why was this solution chosen?
`
Any security threats already considered in the design and why?
`
Threat Brainstorming
- exhuast storage
- no quota
- stored on /data, so could affect other apps
- maybe something in the settings app to manage storage
- write outside specified directories
- don't return of follow symlinks
- '..' or '/' are not allowed
- normalize uri and whitelist, don't blacklist recursion characters
- overwrite/modify/delete user's media
{{#set: SecReview feature goal=* allows content to create/edit/delete files from known locations (define: known locations?)
- use case: give me all the pictures
- hashtable of arrays of files
- mac (~/pictures )
- phone (/data/pictures or /sdcard/DCIM)
- Only is exposed to all certified and trusted Apps not content
- the permission must be specified in the manifest
- Returns array of DeviceStorage objects
- currently access is all or nothing
- proposed to seperate access by permssions (seperate read and create/edit/delete permissions)
- proposed to seperate access by file repository (seperate permissions per repository, or even their own repository)
|SecReview alt solutions=' |SecReview solution chosen=' |SecReview threats considered=' |SecReview threat brainstorming=* exhuast storage
- no quota
- stored on /data, so could affect other apps
- maybe something in the settings app to manage storage
- write outside specified directories
- don't return of follow symlinks
- '..' or '/' are not allowed
- normalize uri and whitelist, don't blacklist recursion characters
- overwrite/modify/delete user's media
}}
Action Items
| Action Item Status | In Progress |
| Release Target | ` |
| Action Items | |
| * Who :: What :: By when
pault: check cjones around sizes/dos risks/paths/partitions dougt**Investigate file blob -> File handle patch** dougt & Djf ** Further investigate permission granularity/implementation** adamm::file bug that isSafePath checks for "." and ".." paths, "..." would get by
|
|
{{#set:|SecReview action item status=In Progress
|Feature version=` |SecReview action items=* Who :: What :: By when pault: check cjones around sizes/dos risks/paths/partitions dougt**Investigate file blob -> File handle patch** dougt & Djf ** Further investigate permission granularity/implementation** adamm::file bug that isSafePath checks for "." and ".." paths, "..." would get by
- Other patterns that have historically caused abuse are in https://code.google.com/p/fuzzdb/source/browse/trunk/attack-payloads/path-traversal/traversals-8-deep-exotic-encoding.txt (ignore %encoded ones in this context)
dougt:: fix bug xxx filed by adamm above }}