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

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. (an analogy in debian packaging terms is that the telco sets the initial contents of the /etc/apt/sources.list file)
4. A user must be able to override the stores which they decide to implicity trust on their devices. (an analogy in debian packaging terms is that the user should be able to set the contents of the /etc/apt/sources.list file)
5. The distribution of applications must scale to mass-volume proportions (100 million or more phones; 1 million or more store-distributed application downloads or updates per day)
6. The distribution of applications must be secure
7. The development of applications must be straightforward, and rapid development cycles must be easy.
8. The security of the distribution of applications through stores must not interfere with, or make awkward, the development of applications.
9. The development of applications by a single developer must not compromise or interfere with the secure distribution of applications via any give store.

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

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 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.

Debian Keyring (Package Management) for distribution of apps

The primary advantage of apt (or yum) package distribution is that it uses person-orientated PKI as the fundamental basis of trust. By contrast, SSL PKI is host-based and thus any distribution model that relies solely on SSL PKI will be tied solely and exclusively to that host. Debian packages, however, being GPG-signed by people, can be distributed without limit or restriction, not even requiring a network (CD or other offline media is possible and supported).

• 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

dealing with rogue applications

this section covers how an application may be replaced if discovered to be malicious

• automatic updates must be enabled (apt-get upgrade)
• people who wish to remain on a "stable" store must have a security-line equivalent to "deb http://security.debian.org/.... "
• rogue applications have a package with a version number "1 higher" than the rogue application's previous package
• the updated package can:
  • be a properly bug-fixed version
  • contain warnings that the user must explicitly agree to prior to acceptance
  • in extreme cases simply replace the files with a blank app that announces "This Application Caused Serious Problems, It Had To Go, Make Sure You Check Your Data N System N Stuff".

debconf shim for B2G / gaia apps

This section is best understood after examining an existing debconf frontend such as debconf-kde-helper in debian, or ubiquity-frontend-debconf in ubuntu. There is also an application in debian called "gkdebconf" which should also be examined. All of these applications communicate with debconf whilst applications are being installed and configured. The front-end deals with presentation of questions to the user, and relays their responses to the installation process.

The proposal is therefore very simply to write a debconf front-end which is also a gaia application. Below is a description of the process.

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

New URI proposal (apt:// or yum://)

This is a very simple proposal to allow applications to be installed in a familiar way (URLs) yet allow the installation process to go through security checks with the minimum of additional programming and modifications to the B2G codebase. A URI could be embedded into application pages (JS or static HTML) for example "apt://phonedialer".

In the instance where that application - phonedialer - has already been installed, the application is activated. However, if the application has not been installed, B2G would hand off the command to apt (or yum, if yum is selected instead). Instead of firing up the application, the debconf shim (see section above) would be activated. This would show the download progress (of both the package and its dependencies), check the digital signatures, run through the installation process including presenting the security questions. Finally at the end, the debconf B2G-aware front-end would be closed, and the application opened up instead.

The syntax for the URI could also be extended to include the specific version of the package to be installed (if required). apt://packagename?version=1.2.1 for example. Also, different archives (stores) could be specified. Doing so would require an additional step in the installation process to add that store to the /etc/apt/sources.list file, requiring the permission of the user before doing so.

Overall this approach has several technical advantages as well as being very simple to understand. If a package is wanted, put "apt://{packagename}" in a B2G web page, anywhere online. B2G devices will know what to do, and will install the package if it's not already available.

For developers however the deployment of the infrastructure required to host an entire debian archive may be too much. In such circumstances however there is a very simple additional proposition which takes care of that: either a deb:// URI or simply to activate installation and execution of packages when a "http://{fqp}/packagename.deb" URL is encountered.

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

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?

The Problem With Using SSL

SSL is a host-based PKI infrastructure. Thus, it ties everything to hosts. Hosts become the target for attacks; hosts become the weak link; hosts become subject to scalability, which, in the context of a million hits a day from a hundred million mobile phones, instantly highlights that SSL is wildly inappropriate (by contrast, the various well-established and proven GNU/Linux distributions use person-based PKI, based around GPG/PGP).

One problem is that SSL (when used with PKI Certificates for Authentication, aka Certificate 'pinning') is that the solution becomes the problem. When a device may only download from a site over HTTPS where only those devices which have the appropriate public key may connect to that site, then if the app becomes popular then the site will quickly be overwhelmed.

The other problem with relying solely on SSL is that it requires trusting the full set of root certificates on the device. This is obviously not a B2G/OWA specific problem but it does seem to be a little worse in this case, especially in hostile environments when the government has or can easily obtain a root cert. This is why we sign desktop Firefox updates as well as verifying them against a hash downloaded over SSL. Defense in depth.

The third problem can be expressed as "faith in SSL is fairly low". In other words, the difference between HTTP and HTTPS is so small that people may be tempted to just start using HTTP, because setting up SSL and getting a PKI Certificate set up is "too inconvenient".

The fourth problem is that SSL doesn't protect against a Server being compromised. In fact, it would give a false sense of security as the SSL Certificate may have been compromised without the server admin's knowledge.

The fifth problem is that, in the case where the private key is distributed widely across multiple hosts in order to spread the load when an app becomes popular, not only must a store have planned in advance to cater for extra demand, but also the wider distribution of the private key makes it more likely that the private key will be compromised.

The sixth problem is that SSL has a processing cost on the establishment of each and every connection, whereas person-based PKI such as that of the debian distribution system requires the package to be digitally-signed once and only once: actually checking the signature is done at the receipient end, and the network infrastructure does not require any actual processing.

Overall, then, the use of SSL can be clearly shown to fail to meet the requirements, and the primary reason is because SSL PKI is host-based security.

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