Apps/Security/Discussion

From MozillaWiki
< Apps‎ | Security
Jump to: navigation, search

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
Note: This page has been subdivided into sections that have their own page but have been transcluded. If it is easier (less intimidating), each section may be edited as its own page.

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

 A level of trust must be established between all four parties: B2G developers, Application developers, users and stores.

 This can only be done at the Operating System (kernel) level.

 Examples include "app can access the IMEI number" and "app can make phone calls".

 This is what is normally considered to be "the web" (XSS in AJAX etc.) and it still has a role to play in B2G.

Additional reading and links:

Definitions

  • WebApp - An application developed with web technologies (JS/HTML/CSS). May contain dynamic and static content (i.e. may make use of eval, script injection as in body.appendChild(createNode("script")) etc.)
  • Native App - A WebApp consisting solely of static content (no script injection or use of eval) 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
  • "bookmarked website" - DEFINITION REQUIRED
  • 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.
  • Content Security Policy (CSP) - A mechanism by which website administrators can define a policy which restricts what domains a website can load resources from
  • 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 (marshalled and unmarshalled) function call parameters 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

Another discussion which mentions "bookmarked website": https://groups.google.com/d/msg/mozilla.dev.b2g/PFaN9HjGkmY/cXTAkRPaGecJ

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

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?

Secure Application Distribution

This section defines how trust is to be established between all four parties: B2G developers, Application developers, users and stores.

Requirements

Distribution / management of WebApps

  1. It should not be trivially easy for a rogue application to be listed on a marketplace / store
  2. The development and release history of an application, including the identity of the developer, should be fully accountable.
  3. A store may revoke a bad / malicious WebApp
  4. A user may revoke a bad / malicious WebApp.
  5. A store may not install ("push") apps onto a device without the user's expressed and explicit permission
  6. A user may remove any app at any time.
  7. A telco can decide which stores to implicitly trust on devices that they sell. (an analogy in debian packaging terms is that the telco sets the initial contents of the /etc/apt/sources.list file)
  8. 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 free to change the contents of the /etc/apt/sources.list file)
  9. 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)
  10. The development of applications must be straightforward, and rapid development cycles must be easy.
  11. The security measures chosen to underpin the distribution of applications through stores must not interfere with, or make awkward, the development of applications.
  12. The development of applications by any developer must not interfere with or compromise the security measures or the distribution of applications through stores.
  13. A developer's application should not, through any technical measure, technical limitation or design flaw in the security model, be restricted to sole and exclusive distribution through any one given and specific store.
  14. Distribution of commonly-used libraries (B2G UI libraries/widget-sets, jquery, prototype, node.js) needs to be controlled and managed
    • multiple versions of the same library need to be permitted, but only one copy of each version of that library permitted
    • there needs to be a way to express dependencies
    • reference counting needs to be added so that when packages are removed, its dependencies are also removed if they are also no longer required.

Proposals

W3C XML Digital Signatures for Widgets

The W3C has a standard for XML Widget Digital Signatures that, on close inspection, shows that it fulfils the requirements. This diagram shows the relationships:

Digsigchain.png

"Stores" correspond to the W3C's definition of "Distributors"; authors correspond to the B2G concept of "app developer".

The only problem with the W3C XML Widget Digital Signature Standard is that, compared to the infrastructure behind GNU/Linux Distributions, which have been deploying Chained-Signing for some considerable time and have a decades-long complete architecture, the W3C's standard was only ratified in late 2011. However, here are some implementations:

  • Java javax.xml.crypto.dsig package: this appears to solely implement the Cryptographic portions of the API: it does not implement a complete store, nor any infrastructure for validating the packages, nor any infrastructure for downloading or distribution of packages.
  • There is a GSoC project to implement it in Apache Wookie, which already has student interest. There is therefore a strong possibility that an open source implementation will exist by the end of Summmer 2012.

On the commercial side, the W3C XML Widget Digital Sigature has been implemented by Opera, Nokia, Vodafone, Samsung, Obigo, RIM and a bunch of web TV platforms as its part of a lot of other spec stacks in the mobile and TV space such as WAC, MPEG-U, HbbTV, CMX (etc).

There have been some packaging and signing tools supporting the specs issued as part of SDKs, e.g. the Vodafone widget packager and the WAC SDK (possibly written by Samsung/Limo). The Blackberry webapps signing tools may also uses widgets-digsig as Blackberry Widgets are W3C Widgets. RIM may have RIM open-sourced most of their Widgets code last year so that may be another lead.

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

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 22, 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: each package has an MD5 and SHA1 checksum.
  • The runtime checks that the binary+signature match and that the signature originates from a trusted public key (of the store)
  • A user may choose to add more sources (stores)
  • A user must add the source's keyring (an app that contains the store's public key(s)) 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 - both the developer's *and* FTP master (marketplace/store) signing the app
    3. compromise or trigger the update mechanism for the app
    4. wait for updates to trickle out without anyone noticing the previous steps.

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".
    • be a completely new name (recommended beginning with "blacklist-") if required. see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

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.

Advantages of People-based security

  • developer keys are part of a comprehensive GPG/PGP web-of-trust that ensures that developers are actually who they say they are.
  • the procedure for stores to identify developers, through that web-of-trust of GPG/PGP keys, is very straightforward (and can be automated, although full automation without some degree of responsible vetting is not recommended).
    • a store could, on discovering a deliberately-malicious app, report the identity of the person directly to law enforcement authorities as well as to the web-of-trust.
  • developers can be requested to GPG-sign an agreement which becomes a legally-binding contract with the store(s). this is similar to CSP. Debian Developers actually do this, very comprehensively: http://wiki.debian.org/DebianMaintainer
  • the security can be upgraded on a rolling basis
    • developers can publish multiple keys into the online keyring, and use the old (less secure?) one whilst they are still establishing the new one in the webring. (note: this has actually happened in debian: a flaw was discovered in openssl and entire teams of GNU/Linux maintainers had to create new keys and revoke the old ones).
    • the "package keyring" can have new keys added to it as well; again, the old key can be used until the new (stronger?) one is well-established.
  • as the store's GPG key is used to digitally-sign "Package Release Manifests", including security update manifests, stable package-list manifests and "bleeding edge" package manifests, users can correspondingly always either roll back to a stable baseline, track security updates (only) or live on the edge, at their own choosing. (see http://ftp.uk.debian.org/debian/dists/Debian6.0.4/, note the "Release" file and its corresponding "Release.gpg" file).
  • there is no actual real link to the actual distribution of the packages once they have been signed.
    • the delivery (transport method) of the packages can be done in-the-clear, over a network or any off-line mechanism that can be creatively devised
    • the distribution range (mirroring) of the packages is literally unlimited (and unlimitable - even peer-to-peer is possible: see http://www.camrdale.org/apt-p2p/ )
    • the limitless distribution does not impact on security, as long as "security updates" are enabled on a user's device (or otherwise regularly checked: it's a "pull" mechanism, not a "push" mechanism).
  • dynamic package updates can be done, by creating a new URI schema (#New URI proposal (apt:// or yum://))
  • security-blacklisted apps can, under the debian scheme (see #dealing_with_rogue_applications)

List of GNU/Linux Distributions that use Package Signing

At this URL is a useful description of how package signing works in various GNU/Linux distributions. https://wiki.archlinux.org/index.php/Package_signing#How_signing_is_implemented_in_other_distributions

This list excludes BSD ports such as FreeBSD. FreeBSD's system is outlined here: http://www.freebsd.org/doc/handbook/portsnap.html

These systems appear to make prevalent use of SHA1 and MD5 (simultaneously) for extra care on checksums: the use of GPG/PGP is also notably prevalent.

It is worth emphasising that AT NO TIME is there any mention of a GNU/Linux Distribution which makes sole and exclusive use of SSL as the method for distribution of applications.

Package Management: Dependencies (libraries)

Apt and Yum have the capability to store not just applications but also libraries, including version numbers. An application may specify that it is dependent on a particular library including the version number (as a range).

The use of such version control and dependencies will help dramatically cut the duplication of UI libraries which are inevitably going to be deployed, even amongst B2G Team Members let alone application developers.

The context here is that B2G could potentially expand to having 100,000+ applications in stores: devices simply do not have unlimited bandwidth or storage capacity to keep on downloading hundreds of copies, identical or otherwise, of jquery or any other javascript library.

SSL as a host-orientated App Distribution System

SSL is being proposed as a means to distribute applications.

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 Store's server admin's knowledge (it is a requirement of SSL that the private key be actually stored on the server).

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.

The seventh problem is that if a certificate-"pinned" store is down, there is absolutely no way for the applications on it to be made available. period. In the case of contentious applications such as privacy-guarding applications, this actually becomes a serious problem especially in light of the USA's misuse and abuse of power to blatantly disregard other nation's sovereign rights over their citizens' legally-owned domain name by seizing them.

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.

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.
Note: Please do not edit this page. Share your ideas in dev-webapps@lists.mozilla.org or Apps/Security/Discussion instead

Permissions

This spreadsheet shows the list of permissions associated with new Web APIs

Note: this table does not include functionality provided to apps via web activities.

Standard web security

Standard web security has a key role to play in B2G. This section defines and delineates the scope of where standard web security (typically involving XSS) is appropriately deployed and used within B2G and B2G applications.

Scope

B2G still needs to display ordinary web pages and media. These should be treated no differently from how they are treated in a normal web browser. However, there is some debate as to whether such ordinary web pages should be allowed to an exceptionally limited subset of B2G's WebAPIs, and there is concern about the ease with which apps may implement phishing attacks

Requirements

  • A standard web page must not have access to any non-standard W3C HTML5 functions, of any kind. (should they have access to some of the "safer" B2G WebAPIs?)
  • The security model for "standard web pages" in B2G must be no different from the standard security model for standard web pages in any normal web browser (including XSS).
  • A standard web page MUST NOT be permitted to operate full-screen, in order to prevent phishing attacks.

Proposals

TBD

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?
  • should script injection - body.appendChild(createNode("script")) - also be restricted?
  • 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 such as script-injection 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
Retrieved from "https://wiki.mozilla.org/index.php?title=Apps/Security/Discussion&oldid=427797"