Security/B2G/PermissionReview/New permission model

From MozillaWiki
Jump to: navigation, search

Goals

  • Reduce number of user facing permissions (merge & deprecate duplicate permissions, map permissions to risk, not APIs)
  • Provide a permission model that supports the new security model

Summary of v3 Changes

  • Web
    • Remove the distinction between "web" apps and regular web content. Make "web" permissions as close to desktop as possible (both user and developer experience)
  • Privileged
    • Most privileged permissions must be gated by some user mediation (since privileged apps no longer need to be installed). Network permissions allowed, but require extra review (TBD).
    • Move implicit privileged permissions to Certified, or make them less dangerous
  • Certified
    • Allow installation of Certified content
    • Open up most if not all permissions to 3rd party content
    • exactly which permissions are available will be determined by marketplace policy, rather than gecko enforcement


Proposed Permission Table

The following is proposed permission table for V3.

Web Content
  • Web APIs: microphone, geolocation, camera, notification, storage, push
  • FxOS APIs: alarms
Privileged Content - signed but not installed
  • Data: contacts, music, pictures, sdcard, videos
  • Personal Details:phone number (mobileid), firefox account
  • Devices: fmradio, nfc, bluetooth, network
Firefox OS Apps - installed signed content & pre-installed content
  • Formerly certified Apps
  • Includes Gaia, Add-ons, Themes & Langpacks
  • Access to APIs governed by marketplace policy (TBD)
    • Some APIs will be Gaia only
    • Some APIs will be available to partners only

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 signed content is not required to be installed, this limits what is safe to expose.

Privileged Permissions are:

  • restricted to signed FxOS content
  • 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)

FxOS App Permissions

All other permissions are App Permissions. All formerly certified permissions will now be available to installed 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. Note this includes add-ons & langpacks.

“Certified Permissions” are:

  • Available to “installed” content only (i.e addons)
  • Access to certain APIs may be limited to partner apps only (TBD)

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)
Retrieved from "https://wiki.mozilla.org/index.php?title=Security/B2G/PermissionReview/New_permission_model&oldid=1081094"