Apps/Security

Boot 2 Gecko App Security Model Discussion

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
• Track the status of B2G_App_Security_Model/Threat_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
• Gaia App - DEFINITION REQUIRED
• B2G App - DEFINITION REQUIRED which is meaningful in the context of the above app definitions
• Store - A marketplace where a user may download/purchase WebApps for their device
• above definition are up for discussion
• Extended Validation (EV) Certificate - A SSL certificate that undergoes additional authentication / verification steps before issuance.
  • Explanation
  • Verification process
• Content Security Policy (CSP) - A mechanism by which website administrators can define a policy which restricts what domains a website can load resources from
  • Specification
• XPCOM - a Common Object Model that is 'inspired by' Microsoft's COM. It is reasonably feature-complete but does not contain co-classes. The implementation is also entirely missing a marshalling / unmarshalling (serialisation) layer.
• ncalrpc - a local networking protocol that is used in Microsoft's COM to efficiently communicate data between COM clients and COM servers that are on the same machine. http://msdn.microsoft.com/en-us/library/windows/desktop/aa378665%28v=vs.85%29.aspx

Important reading! B2G applications are Open Web Apps, you can read about them here: https://developer.mozilla.org/en-US/apps

Concepts to be given Official Definitions

There is no real easy way to distinguish the following, all of which are iframes (!) in the B2G environment. There is some considerable confusion as a result, especially due to the fact that the required security context and especially the interactions between parent and child iframes are different depending on the type of iframe.

Names really therefore need to be given to the following:

• the root frame (top-level one into which the top gaia HTML is loaded)
• individual gaia apps (sub-iframes, one per app)
• any gaia app that opens up a public-facing (URL-based) iframe in which the contents of a URI are displayed: the browser app is one such
• iframes *within* that iframe - as in "iframes that you normally think of iframes being used for as an ordinary web developer".

Discussion which raises the issue of confused definitions, helps clarify them: https://groups.google.com/d/msg/mozilla.dev.b2g/AQYPkIjKxjE/WYy0LPta9cMJ

App instance / version

(Note: this section is very much in an informal style that includes definitions, discussion as well as functional analysis. it should be analysed and split up appropriately.)

• 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 controls
• 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

Bugs

• bug 707625 - WebAPI permissions manager

Introduction

There are four separate areas where security work is required. Each area is separate but inter-related. Each is required and cannot be ignored.

1. Secure Application Distribution. A level of trust must be established between all four parties: B2G developers, Application developers, users and stores.
2. Application Permissions Enforcement. This can only be done at the Operating System (kernel) level.
3. Definition of the permissions to be enforced. Examples include "app can access the IMEI number" and "app can make phone calls".
4. Standard web security. This is what is normally considered to be "the web" (XSS in AJAX etc.) and it still has a role to play in B2G.

Summary

This page is intended to be a high level summary of the current B2G/Open Web Apps, for the purpose of breaking out the discussion into seperate topics. Feel free to add to topics, or create new ones as required, but try to keep this page succinct enough so that it is useful as a reference to the discussion.

Core Principles

1. User control: Users control what application permissions an application has at all times (pre, during and post installation).
2. Secure by default: A user who chooses to accept the default permissions recommended by a store must be secure by default
3. Least Privilege: Applications must be granted the minimum privileges necessary to function (in a Capabilities Model this translates to: Applications and/or their plugins must have the minimum functionality installed and must not see any functions other than those which they are permitted to use).
4. Minimize Permissions: APIs should be designed in such a way to provide the most functionality without the need to be granted permissions

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.

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.

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

Trust Model

1. The user is the root source of trust for permissions settings.
2. B2G devices will be shipped with a root Trusted Store which has the power to set the permissions defaults for an Web App.
3. The user can choose to override store permissions (either granting or revoking privileges), but the store permissions should be safe for the user, and represent the minimum permissions the application needs to run.
4. The store can also entrust other stores with the power to grant permissions (possibly a subset of permissions, or not privileged permissions)

Security Requirements for Critical App Deployment

Still under heavy discussion. (Trusted Stores, Code Signing etc)

• Which permissions will be classed as sensitive
• What will the minimum bar be
  • Trusted App Host?
  • Code Signing?
  • Both? Something Else?
• Will there even be a separate set of requirements, or will threats be mitigated by App Store processes instead?

Requirements

(This section describing requirements was developed/written separately from the 4 security areas outlined above. both areas must be consistent and integrated)

Core Principles

1. User control: Users control what application permissions an application has at all times (pre, during and post installation).
2. Secure by default: A user who chooses to accept the default permissions recommended by a store must be secure by default
3. Least Privilege: Applications must be granted the minimum privileges necessary to function
4. Minimize Permissions: APIs should be designed in such a way to provide the most functionality without the need to be granted permissions

Trust Model

1. The user is the root source of trust for permissions settings.
2. B2G devices will be shipped with a root Trusted Store which has the power to set the permissions defaults for an Web App.
3. The user can choose to override store permissions (either granting or revoking privileges), but the store permissions should be safe for the user, and represent the minimum permissions the application needs to run.
4. The store can also entrust other stores with the power to grant permissions (possibly a subset of permissions, or not privileged permissions)

Enforcement of permissions on device

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

App/Security/Distribution

Application Permissions Enforcement

This section defines how permissions are to be enforced at the Operating System (kernel) level. B2G is defined as a "full Operating System" and thus requires kernel-level enforcement of permissions (A Linux Kernel based Security Model). In the Android Operating System, collaboration and cooperation is carried out between the Linux Kernel Android Security module and the userspace Android Applications: the exact same principle is required - translated into the B2G Operating System world.

Requirements

• It must not be possible for any one binary executable being compromised to result in a total systems and security failure.
  • Compromise of the main B2G executable must not result in complete control of the device (e.g. dialer, GPS, camera)
  • Compromise of an individual component (e.g. GPS) must not result in any other area (dialer, camera, main UI) being compromised
• Application Developers should be presented with easy bullet-point style permission sets that can be applied to their application.
  • These should map easily onto the enforcement within the underlying OS security model

Proposals

FLASK and SELinux for enforcing permissions

The Flask Architecture makes it possible to implement various Access Control systems. SELinux is technically an implementation of Mandatory access control based on Flask Architecture.

• 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 (in the new executable) depends on who you were, where you are *AND* what the current executable is."
• Adopting for use in B2G means writing an interface that mediates API / systemcalls
  • Suggestion was a JSONRPC service, because even without SELinux, one executable cannot compromise another executable merely across a socket boundary: it would be necessary for the compromised executable to attempt buffer-overruns (etc.) of the service (even if the service was on the same machine).
  • Another suggestion is to implement "NCALRPC" in the underlying XPCOM infrastructure, which would allow XPCOM-based components to seamlessly communicate entire functions across executable boundaries.
• 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 in the current implementation 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.

Full Discussion on NSA's SE-Linux Mailing List: http://marc.info/?l=selinux&m=133190422130989&w=2

Summary points of Discussion on NSA's SE-Linux Mailing List:

• As B2G is based on Android, it may be worthwhile investigating http://selinuxproject.org/page/SEAndroid
  • Apart from anything it will save time on developing the base permission set (to cover the main OS)
  • SE-Android is being developed by the NSA specifically to avoid the need for Android developers to get involved with the "low-level" SE-Linux permissions system.
• Stephen Smalley (NSA) has the following recommendation: See http://www.nsa.gov/research/selinux/related.shtml for some links to work done to apply Flask to various other applications like PostgreSQL, Xorg, and D-BUS.
  • Following Stephen's recommendation would allow the creation of very special permissions that are specifically relevant to B2G, for proper enforcement at the Linux Kernel level.

Other

This section contains questions, sections and comments whose purpose has not been made clear, and open issues.

Kernel 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