177
edits
Changes
m
=== 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 (marketplace/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.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-{packagename}" 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.
no edit summary
=== Permissions manager ===
*** 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 (marketplace/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.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-{packagename}" 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.
= Application Permissions Enforcement =
