Security/B2G/PermissionReview/New permission model: Difference between revisions

Jump to navigation Jump to search

Security/B2G/PermissionReview/New permission model (view source)

Revision as of 05:40, 1 June 2015

1,901 bytes removed ,  1 June 2015
Update content
(update summary)
(Update content)
Line 7: Line 7:
** Allow installation of certified apps (exactly what permissions are available will be determined by marketplace policy, rather than gecko enforcement)
** Allow installation of certified apps (exactly what permissions are available will be determined by marketplace policy, rather than gecko enforcement)


=== Simplify Permissions model ===
Changes to FxOS Permissions Model are proposed to improve the model, and bring it closer to the web’s permission model where possible, and make the model easier for both users and developers.
The key changes are:
* Remove the distinction between "web" apps and regular web content. Make "web" permissions as close to desktop as possible (both user and developer experience)
* Move most certified permissions to be "privileged". We won't necessarily be exposing all permissions to 3rd parties, but this will be a policy decision, and allow us flexibility without the need to change gecko in order to change permission policy.
* For privileged permissions, provide improved permission granting UX, which provides effective mitigation of the new risks introduced by "linkable, non-installed" privileged apps
* Improve permission management UX to support the new "app-less model"
* Reduce the overall number of permissions categories exposed to users & developers through consolidating permissions where possible


=== Proposed Permission Table ===
=== Proposed Permission Table ===
Line 32: Line 22:
* Data: contacts, music, pictures, sdcard,  videos
* Data: contacts, music, pictures, sdcard,  videos
* Personal Details:phone number (mobileid), firefox account
* Personal Details:phone number (mobileid), firefox account
* Devices: fmradio, nfc, bluetooth
* Devices: fmradio, nfc, bluetooth, network
* Capabilities: browser, network, input, homescreen
|-
|-
| Certified Permissions
| Certified Permissions
|
|
* Only permissions which will never be exposed to 3rd parties
* All other permissions
|}
|}


TODO: add certified permissions & mapping of old permission to new permissions
Web Permissions
“Permissions” are defined are the permissions available to all content. The characteristics of web permissions are:
generally granted by the user at first use, usually through prompting
Are NOT required to be declared in an application manifest (declaring these permissions will be allowed to provide backwards compatibility).
permissions are generally granted via prompt at runtime, upon first API call.
some permissions require additional UX for risk mitigation (e.g. storage & alarms need a way for the user to manage them - i.e. managed disk usage, review/delete alarms
provide a way for users to see apps which consume large amounts of storage
provide a way for users to see when alarms are set, mitigate the risk of web pages waking you up on the middle of the night, or showing ads repeated with alarms
Privileged Permissions
Privileged permissions are an additional set of permissions which signed content can request, after going marketplace review. Because privileged content is no longer installed, this limits what is safe to expose.


ISSUE: Do we need to keep the certified permissions?
“Privileged Permissions” are:
 
restricted to signed FxOS content
Issue: Can we trust marketplace to be enforcer of what apps can get permissions? Where will we track the permissions matrix (PermissionsTable.jsm is the source of truth for permissions mappings at the moment, where will it be in the future)?
must be declared in manifest
 
permissions are no longer granted at install (no install process)
Issue: Are there still any APIs that have to run in system app/parent process (embed-webapps, open-remote-window)? How can we enforce this?
granted by prompt after the app content first loaded (assuming app signature verification passes)
 
Certified Permissions
Issue: Many APIs are currently restricted by App type rather than a permission. This includes (not complete list):
All other permissions are certified. Certified permissions will now be available to installed add-on content. However not all certified permissions are safe to expose. We will need to come up with marketplace policy for granting permissions on a per-app basis.
*DOM APIs guarded by [AvailableIn=CertifiedApps] in WebIDL (with no permission check)
*Inter-app communication API
*Datastores API
*navigator.mozResendAllNotifications
 
Issue: If we remove certified app type and APIs completely, vendors won’t have a way to add APIs that are restricted to pre-installed content. (vendors shouldn’t need to add APIs, but the reality is that they do, maybe engineering-mode will reduce the need for this?)
 
Issue: Privileged apps are signed. Certified apps are not. Will pre-installed privileged apps need to be signed?


“Certified Permissions” are:
Available to “installed” content only (i.e addons)
Controlled by marketplace policy rather than
Open Issues
Existing privileged permissions are too dangerous
data APIs need to be made more safe (one wrong click and you lose all your photos?)
network APIs are implicit (not prompted). We need to make these APIs safer, or figure out a stronger review process to mitigate risk of abuse
Certified permissions will need to be regulated by marketplace,not all permissions will be grantable to 3rd parties. Need to determine policy for  which permissions will be allowed and under what circumstances.
Can we trust marketplace to be enforcer of what apps can get permissions? Where will we track the permissions matrix (PermissionsTable.jsm is the source of truth for permissions mappings at the moment, where will it be in the future)?
Are there still any APIs that have to run in system app/parent process (embed-webapps, open-remote-window)? How can we enforce this?
ISSUE: Many APIs are currently restricted by App type rather than a permission. This includes (not complete list):
DOM APIs guarded by [AvailableIn=CertifiedApps] in WebIDL (with no permission check)
Inter-app communication API
Datastores API
navigator.mozResendAllNotifications
Issue: Privileged permissions granted by user are revocable. If we keep current model, users could revoke permissions from Gaia apps, breaking them. (See below for more details)
Issue: Privileged permissions granted by user are revocable. If we keep current model, users could revoke permissions from Gaia apps, breaking them. (See below for more details)
=== Simplify permissions model ===
We will split the existing permissions into two categories:  “Web Permissions” & “Privileged Permissions”. (Note that I'm omiting certified permissions here as these are intended to be internal permission visible only to b2g developers)
We want to better define the two types of permissions that are exposed to user & developers (web & privileged) and more clearly define the attributes of each.
==== Web Permissions ====
“Permissions” are defined are the permissions available to web content (be it app or regular web content). The characteristics of web permissions are:
* generally granted by the user at first use, usually through prompting
* Are NOT required to be declared in an application manifest (declaring these permissions will be allowed to provide backwards compatibility).
* permissions are granted at runtime, upon first API call
* some permissions require additional UX for risk mitigation (e.g. storage & alarms need a way for the user to manage these)
Issue: what will be the impact of removing forward declaration of app permissions in the manifest? Settings UI will have to have same options for all apps. Potential for users to grant permissions that the app never uses, but this is how it works on desktop.
==== Privileged Permissions ====
“Privilege Permissions” are defined as:
* Control access to APIs restricted to signed FxOS content
* must be declared in manifest
* permissions are no longer granted at install (no install process)
* granted by prompt after the app content first loaded (assuming app signature verification passes)
ISSUE: what do we do with the existing IMPLICIT privileged permissions ?
==== Certified Permissions ====
* Same as existing, except most certified APIs are moving to privileged
* Only APIs which we will _never_ expose (at least in current form) will be kept in certified
=== Exposing APIs to the web ===
The risks that need to be mitigated when exposing APIs to the web are listed here:
https://wiki.mozilla.org/Security/B2G/PermissionReview/Hostedrisks
*Making APIs directly available to the web, still under discussion:[[Security/B2G/PermissionReview]]
* Review of all API permissions: https://docs.google.com/a/mozilla.com/document/d/1Ew5xEQYD_pBKZdoU_A986au6LiRWxjVkgb72Hj3kzUA/edit
* Providing a framework for privileged apps to provide mediated access to privileged APIs: https://groups.google.com/d/msg/mozilla.dev.b2g/G2opSeeUYD0/N5_Zooi9SL4J
Ptheriault
canmove, Confirmed users
1,220

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1077537"

Navigation menu