= 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 ===# It should not be trivially easy for a rogue application to be listed on a marketplace / store# The development and release history of an application, including the identity of the developer, should be fully accountable.# A store may revoke a bad / malicious WebApp# A user may revoke a bad / malicious WebApp.# A store may not install ("push") apps onto a device without the user's expressed and explicit permission# A user may remove any app at any time.# 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)# 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)# 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)# The development of applications must be straightforward, and rapid development cycles must be easy.# The security measures chosen to underpin the distribution of applications through stores must not interfere with, or make awkward, the development of applications.# The development of applications by any developer must not interfere with or compromise the security measures or the distribution of applications through stores.# 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. == Proposals ===== 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:*# compromise the site hosting the app*# compromise the keys - both the developer's *and* FTP master (marketplaceApp/store) signing the app*# compromise or trigger the update mechanism for the app*# 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//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. # a user goes to a store (GUI front-end TBD)# this "store" triggers the command "sudo apt-get update" in the background (or this occurs on a regular basis)# they go "i wanna app wiv a cherry on top"# the selection fires off a LOCAL COMMAND "sudo apt-get install cherry-on-top".# the GUI uses the dpkg / debconf communication system to inform them of progress# 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]])** be listed on an equivalent of http://security.debian.org (see Debian Security Advisory list)** have a special replacement package which even renames the package to "blacklisted-{packagenameDistribution}" by adding a "Replaces: {packagename}" into the package's control file. (see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces) === 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. === 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 =
