B2G App Security Model

Status

Team

Open issues/risks

What unique types of apps do we support (local installed with special privileges, local installed with normal privileges, remotely hosted but locally installed, remote apps within browser)?

Will B2G have an "installed apps" mechanism for installing static offline applications, or will all apps be loaded over the web (using Offline Web Application API as necessary for offline mode)?

How should apps with "special" privileges be managed (identified, discovered, installed, updated)? Do they require a different security model?

What restrictions should exist for code and content importing for apps (remote to local, cross-domain)?

Which types of applications need to be signed? (if so how, and what will be signed?)

How does an app store blacklist / revoke an application?

Should permission requests/notifications happen at install time, at runtime, or both?

Should permissions be opt-in or opt-out?

Should apps be notified when permissions are denied for a given app, or should permission failures be indistinguishable from other failure modes?

Exploit mitigations for in-content attacks (i.e. code injection, MITM)

Exploit mitigations for memory-safety attacks (multi-process with restricted rights for app processes)

User control: Can the user always override the permission settings for an app?

Stage 1: Definition

1. Feature overview

The B2G app security model governs how applications are discovered, installed, managed, run and updated.

This feature page is tracking these requirements independently of the general Mozilla Open Web Apps security model even though we expect the models to be compatible, since B2G has specific issues that need to be considered in addition to browser-hosted applications.

2. Users & use cases

Users may obtain apps from a number of different stores, including a Mozilla application store, vendor or carrier application store, or other 3rd party stores. Some of these apps may have special privileges (such as a phone dialer) that may require additional controls or extra authentication.

Users should be able to discover, installed, run, update and uninstall application as they see fit. These applications should be able to run offline. Users should also be able to manage the security and privacy relevant settings for those applications, potentially at different phases of the apps lifecycle (at install, at runtime, independently).

3. Dependencies

Heavily dependent on the Open Web Apps security model and ecosystem (including Marketplace), and on BrowserID as well.

4. Requirements

• An app store needs to be able to approve an application, implying they can verify the permissions, integrity and authenticity of the app
• App store needs to be able to revoke an app
• App store must be able to set the default permissions for an app
• A user needs to be able to make a trust decision at install time, so they also need to be able to verify the authenticity, integrity and privileges of an app
• User has control of the permissions of the app throughout its lifecycle, overriding those set by the app store if desired
• Apps should be able to discover their privileges and degrade gracefully in a limited privilege environment
• Permissions need to be expressed to the user in a way that they can realistically be expected to comprehend (perhaps with options for power-users)
• Permissions requested / set need to be enforced.
• Apps should not be vulnerable to common web vulnerabilities when granted significant privileges
• Ability to grant trust for certain highly sensitive privileges (such as phone dialing) may be restricted at the OS level to specific trusted parties

Non-goals

`

Stage 2: Design

5. Functional specification

The current state of the application security model is located here: Apps/Security

A threat model is being documented here: B2G_App_Security_Model/Threat_Model

WebAPI permissions manager implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=707625

Design Decisions Made

• One app per origin (FQDN) where app URL may potentially be a new URI type
• Multiple App stores
• Apps are peers to their native equivalents from an experience standpoint
• Four types of web applications

6. User experience design

`

Stage 3: Planning

7. Implementation plan

`

8. Reviews

Security review

`

Privacy review

`

Localization review

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

`

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes