Apps/Security

Boot 2 Gecko / OpenWebApps Security Model

Note: This page is for capturing information about the B2G/OWA security discussion. This document should not be considered authoritative at this time

• Track the status of B2G_App_Security_Model

Bugs

• bug 707625 - WebAPI permissions manager

Requirements

Distribution / management of WebApps

1. It should not be trivially easy for a rogue application to be listed on a marketplace / store
2. A store may revoke a bad / malicious WebApp
3. A telco can decide which stores to implicitly trust on their devices

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

Enforcement of permissions on device

1. Permissions should be enforced regardless of version of B2G installed

Proposals

App instance / version

• Last updated March 14, 2012
• Possible definitions of what an app instance / version is
  1. a static bundle of code authenticated by manifest + signature (or equivalent)
  2. a dynamic stream of code authenticated by a specific origin (same origin applied, all assets must be loaded from https://<a host>)
  3. an initial loader authenticated by a specific origin (https://<a host>), which can then load whatever it wants
  4. unauthenticated code loaded over any channel, from any origin
• loosely ordered from best to worst (descending) security wise
• 1) and 2) could work with additional security mitigations
• attacker can use option 2) as a proxy for malicious content
• attacker can use option 2) as proxy to paid app (buy once, share with world)
  • mitigation for this may be responsibility of app developer
• CSP can secure 1) and 2) to an extent
  • define baseline CSP policy that apps have to adopt
• See Intro to AIR security

Trusted store with permissions delegation

• Mozilla (telco store) acts as an authority for permissions requests
• WebApps request permissions in manifest
• Each store contains a set of permissions they can grant
• The "root" store may grant any permissions
• A store (parent) may permit a trusted store (child) to grant a subset of parent's permissions
  • ACME is a root store
  • ACME allows Roadrunner Store to grant (Throw, Eat) permissions to WebApps it trusts
  • Roadrunner Store may further permit Coyote store a subset of (Throw, Eat) permissions
  • Coyote Store may then grant WebApps it trust a subset of what Roadrunner Store granted
• Permissions granted to a WebApp are the intersection of permissions requested by manifest and permissions a store may grant
  • WidgetIncApp is listed on ACME store
  • WidgetIncApp requests Hammer, Nail permissions
  • ACME store has been granted Hammer, Screw permissions by telco
  • WidgetIncApp receives (Hammer, Nail)∩(Hammer, Screw) == Hammer permissions
  • There was discussion of a "privileged store" which is a store blessed to allow access to certain APIs such as dialer
  • "blessed" apps must always be served from the store with access to source code
• Selfhosting of WebApp
  • A WebApp can be self-hosted and query a trusted store on install
  • The WebApp will be granted permissions based on what the trusted store would have granted the WebApp
    • WidgetInc wants to host WidgetIncApp from widget.lol
    • WidgetInc has already uploaded WidgetIncApp to ACME Store
    • User visits widget.lol to install WidgetIncApp which contains a pointer to ACME Store
    • Runtime queries ACME Store to see what permissions should be given to WidgetIncApp

FLASK for enforcing permissions

• Tested architecture that is used SELinux
• Follows a mandatory access control model where no permissions are granted by default
• There is no inheritance of ACLs / permissions
  • If a WebApp were to change / do something new, it wouldn't have its old permissions
• "what you can do depends on who you were, where you are *AND* what you're executing."
• Adopting for use in B2G means writing an interface that mediates API / systemcalls
  • Suggestion was a JSONRPC service
• API access would be enforced across security contexts
  • e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.

Debian Keyring (Package Management) for distribution of apps

• Last updated March 14, 2012
• Items in () denote the equivalent in WebApp world
• infrastructure already exists
• Code is cryptographically signed by multiple parties
  • Package (WebApp) maintainer (author / company)
  • Package is signed by FTP masters (marketplace / store?)
• Signed packages / manifests are separate from binaries (HTML content)
  • We need a way to verify that the WebApp content has not changed
• The runtime checks that the binary+signature match and that the signature originates from a trusted keyring (store)
• A user may choose to add more sources (stores)
• A user must add the source's keyring (store's public key?) to disable warning about untrusted source
• To compromise an app with proper code signing requires
  1. compromise the site hosting the app
  2. compromise the key(s) signing the app (assuming you require app updates to be signed with the same key)
  3. compromise or trigger the update mechanism for the app
  4. wait for updates to trickle out

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

Other (topics that don't fall into above proposals)

• Last updated March 14, 2012
• SSL should be used for content delivery
  • can provide authentication for client-store communication
    • complicated compared to code signing since each mirror will either need same key or store/app needs to know each valid mirror
  • provides end-to-end security
  • does not address concerns of a malicious app
• W^X / NX for WebApps

Open questions

1. What happens when a WebApp is revoked?
   • removed from store?
   • removed from user device?
   • refund?
2. What is the identifier used when a WebApp is revoked?
   • origin (scheme + host + port)
   • certificate / hash embed inside WebApp manifest
3. Should eval() and similar functions be considered sensitive APIs / restricted?
   • Adobe AIR restricts eval() in the application sandbox (docs)
4. Should self-signed certificates be allowed?
5. What would be signed?
   • CSS
   • scripts
   • content
   • other