Security/AppsProject/B2GDeviceStorage: Difference between revisions
(Created page with "{{SecReviewInfo |SecReview name=B2G Device Storage }} {{SecReview}} {{SecReviewActionStatus |SecReview action item status=None }}") |
No edit summary |
||
| Line 1: | Line 1: | ||
{{SecReviewInfo | {{SecReviewInfo | ||
|SecReview name=B2G Device Storage | |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 | |||
}} | |||
{{SecReview | |||
|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 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 | |||
}} | }} | ||
{{SecReviewActionStatus | {{SecReviewActionStatus | ||
|SecReview action item status= | |SecReview action item status=In Progress | ||
|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 | |||
}} | }} | ||
Latest revision as of 14:15, 12 June 2012
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 }}