Apps/Security/Permissions

Permissions Definitions and Presentation

This section discusses the actual permissions to be enforced (as distinct from the method of enforcement, how and what should be presented to the user, including the management, and the implications at the application level (if permissions are or are not granted).

Scope

Process for granting permissions

1. By default all Web Apps have the no special permissions, the same as any other web page.
2. A Web App requests permissions in the manifest when submitting to a store (an application may only be granted permissions that it requests in the manifest)
3. An App Store can grant permissions to a Web App during the install process (but not necessarily all of the requested permissions
4. The user’s default permission policy is applied to the requested permissions (see permissions management) and requested permissions are updated
5. The user is informed of the permissions during installation, and can modify them if desired, or choose to trust the defaults set by the App Store.

Note: If sensitive permissions are requested, certain security requirements may be placed on the application.

(comment: this section appears to be in discussion or proposal form, not a summary form. as such it should be moved to a suitable section)

Types of Runnables

The scope of the permissions model is limited to Open Web Apps, which are applications written web technologies (HTML, JS, CSS). These are the only applications which are installed on B2G, "the web is the platform", there are no user-installable native apps.

There are multiple layers of applications underneath these web apps, which make up the B2G OS, but these are beyond the scope of the permissions model. It is noted however that the permissions model might influence the design of lower layers: for example, ideally Web Apps of differing permission levels would be sandboxed to limit the impact of memory corruption vulnerabilities. For further detail on the underlying B2G architecture see: B2G/Architecture

Requirements

Permission Types

1. For privacy-related permissions, the user must always be asked, unless they have overridden
2. Permission values:
   1. Deny
   2. Prompt (default to remember)
   3. Prompt (default not to remember)
   4. Allow
3. List of Permissions: TBD

Management / granting of API permissions to WebApps

1. User should be able to view / control / modify permissions granted to WebApps
2. WebApps should fail gracefully if not all permissions granted
3. User should have control over APIs with privacy implications
4. User should be able to audit usage of permissions (this is different from viewing what permissions an app has, since that does not tell you how or when it is used)
5. Apps must not request permission to do something or use a function that it has not declared that it needs to do. (TBD: If an app attempts to execute a function which the user has not authorised, what action should be taken? terminate the app? remove it? report it?)

discussion links:

1. https://groups.google.com/forum/#!topic/mozilla.dev.b2g/AQYPkIjKxjE

Management of Permissions

1. A user can modify the permissions granted to a Web App at any time including granting or revoking privileges
2. Permissions can be granted per application, or set globally in the Default Permission Policy (see below)
3. Users need to be guided on the consequence of changing permissions, and protected from making choices which are insecure or which could disable their device (e.g. removing the permissions setting capability from the permissions web app)
4. Permissions can be modified either through a permission manager application, or set through contextual actions (e.g. response to security prompts including "remember me" checkboxes or through behavior in some cases, e.g. user ignores a prompt five times in a minute, don't prompt again for an hour)

Default Permission Policy

Each B2G device has a default permissions policy which takes precedence over the app store. This is expected to contain rules for a subset of permissions.Its purpose is:

• for device manufacturers to set safe default limits for permissions
• for users to decide on global limits for permissions

For example, a default setting for location might be that even apps, which are granted access to location, must always ask the user. This could modify this policy to be more strict, and globally deny applications from accessing location information.

A user should be warned before they override the Default Permission Policy in an unsafe way.

Required Application Permissions

This section lists the actual permissions that are required to be enforced (at the Operating System Level)

• Full-screen mode
  • Interaction (events allowed and to which areas?)
• Phone Access
  • Emergency Services
  • Ordinary calls
  • Premium Rate numbers (?)
• SMS
  • Read
  • Send
  • Delete
  • Address book read
  • Address book modify
• GPS
• EMEI Number
• Camera
• USB devices

Proposals

Capabilities Model: Absolute Minimalist (no) Permissions presentation to Users

One major concern is that users simply do not have a clue what they are doing. The "click the box" syndrome. It therefore makes some sense to simply not present any permissions dialogs at all to the user, but instead for all decisions, all warranties and all reviews regarding the security and privacy of an application to be made by the Mozilla Foundation, the application developer and the store(s).

Whilst at no time will an application not receive a full review and security audit, and whilst there would still be a complete and full set of permissions, the proposal is simply that the user is simply given one choice: install application based on what it says that it does, or don't install application. The user can read up on the application's capabilities, must agree to its license, and no more.

Under these circumstances, variants of the application may be released, as well as plugins to that application, which extend its capabilities.

This is known as a "Capabilities Model", as an alternative to "Access Control". If a user is not permitted or is not to be given a choice to carry out certain functions, under the "Capabilities Model", the functionality is removed i.e. not even present on the system at all.

Permissions manager

• User can deny permissions at install time
• User can always go to manager to see what permissions an app has been granted
• User can modify permissions through the manager
• Certain APIs are defined as "sensitive"
  • Sensitive APIs will request "capabilities" e.g. access USB, access wifi
• Levels of access for capabilities
  • Allow
  • Prompt (default to remember)
  • Prompt (default to not remember)
  • Deny
    • There were concerns that the levels should only be Allow/Deny
• Contractual enforcement of permissions
  • WidgetInc may come to Mozilla (telco) with request for access to sensitive APIs
  • Mozilla (telco) may draft a contract with WidgetInc giving them access to the sensitive APIs under certain conditions
• WebApps may be granted default permissions
  • e.g. access to storage, access to change context menu
• capabilities may be restricted based on technical restrictions of the site
  • e.g. strict-transport security, EV-certificate