Apps/Security

Boot 2 Gecko / OpenWebApps Security Model

This page is for capturing information about the B2G/OWA security discussion.

Note: This is not a design document and should not be considered authoritative at this time

• Track the status of B2G_App_Security_Model
• OWA developer page

Definitions

• WebApp - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content
• Native App - A WebApp consisting solely of static content and run on a B2G capable device
• Store - A marketplace where a user may download/purchase WebApps for their device
• above definition are up for discussion

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
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 cannot request permission to do something that is not listed in the manifest

discussion links:

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

Enforcement of permissions on device

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

Proposals

App instance / version

• Note: 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

Types of Runnables

There are 4 (or more) types of possible runnables so far identified on B2G:

• 0) Kernel, drivers (including virtual device drivers), CLI tools(including services), browser engine and (maybe) plug-ins.
• 1) Packaged programs (i.e. B2G Gaia apps that are written in HTML/CSS/JS)
• 2) Installed non-local Web apps (including sites).
• 3) Non-installed Web apps (including sites).
• 4) B2G (Gaia) apps (same as 1) but manually installed in /usr/local, bypassing the Packaging system

(It seems all type 1 runnables can be implements as type 2 or 0. Maybe we needn't treat them as a seperate type)

For type 0 & 1, a deployment mechanism like apt/yum works fine (and seems required for type 0). But for type 2 & 3, such mechanism may not cover. I'm afraid that many apps will be implemented as type 2 or 3 for smooth of (re)deployment (and this is a huge advantage for web apps to native ones).

Trusted store with permissions delegation

Note: Last updated March 14, 2012

• 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

  • Note: This is opposite of the FLASK model which does not use a permissions hierarchy. There are problems if a child store inadvertently grants too permissive of permissions to an app (genie out of the bottle).

  • 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 an executable were to change / do something new, it wouldn't have its old permissions: it is given entirely new ones
  • However this means that B2G must be broken down into separate executables, communicating via files, sockets etc. (as opposed to running multiple threads and processes sharing the same easily-corruptible memory-space and file descriptors)
• "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, because when protected by SELinux, one executable cannot compromise another executable merely across a socket boundary.
• 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.
  • an app, which for best results would run either its javascript engine or better its own entire gecko engine as a separate executable, would be granted a security context which allowed it only the rights to execute or access other programs (such as a dialer).
  • in the case of JSONRPC service(s), the app would be granted SE/Linux permissions to access the URL which activated the dialer (this is one possible implementation)
• use of WebAPIs is impossible to properly protect against compromise. once a process or thread is compromised, all other threads and processes must also be considered to be compromised.

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 the following extremely difficult tasks to be carried out:
  1. compromise the site hosting the app
  2. compromise the keys (developer *and* FTP master) 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

debconf shim for B2G native apps

1. a user goes to a store (GUI front-end TBD)
2. this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)
3. they go "i wanna app wiv a cherry on top"
4. the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".
5. the GUI uses the dpkg / debconf communication system to inform them of progress
6. the GUI then walks them through the security questions (which is all part of debconf)

• we would distribute a debconf frontend app for B2G
• B2G app communicates with dpkg/debconf through something like a unix pipe
• the fetching of the app is an implementation detail, FTP, rsync, HTTPS doesn't matter as long as the package is properly signed
• B2G app only receives progress updates
• it may be possible to leverage the existing Debian package infrastructure

  • Note: If leveraging the good-will of debian to host B2G and also Gaia apps, there may be license (advertising clause) issues that need to be resolved

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

Centralized permissions manager

{lkcl.15mar12.2223hrs - it's not clear to me what this section refers to: a userspace application that interacts with the user to help them select the level of access that they wish to grant to a particular application, or to the actual kernel-side implementation that enforces the permissions, or a developer "assistance" suite of software which helps the developer to create the permission set that's to be associated with the application when it's installed}

• separate process that controls access to permissions
• responsible for
  1. query permissions, true/false if permissions X is granted
     • support for prompting user in event permission isn't granted
  2. add / remove permissions
  3. audit permissions
  4. support observers for permission change
• permissions requested are based on "uri signatures"
  • to be determined what the signature is: domain, partial url, other?
• permissions representation
  • type - usb, web, radio, etc
  • uri signature
  • value
  • source - user, manifest, system
  • expiration type - never, time-based, session, other?
  • expiration time
  • allow message - for UI / prompting user
  • deny message
• app obtains permission by querying / asking central process
• OS support required for properly constructing signature, app should not be able to influence this
  • there needs to be a unique identifier than an app can't spoof
• permissions requests can be cached
  • cache needs to be invalidated on permission change

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
• should the JS "eval" function have a permission added to it?
• bypassing the official package system speeds up app development
  • at the risk of destabilising a system!
  • should still be allowed though (with caveat that warranty just got voided)
  • concept of /usr/local and /usr should be mirrored in B2G with e.g. /usr/gaia/apps and /usr/local/gaia/apps
• self-host discussion http://groups.google.com/group/mozilla.dev.b2g/msg/b079d34ccdec0f85
  • The scenario is that we have an untrusted store attempting to sell an app which is hosted on a trusted store, how is this solved?

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