FirefoxOS/New security model/Packaging: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 124: Line 124:
Verification failures are generally treated as network failures. See "Error Recovery" below for the approach to dealing with loading errors and partially loaded apps.
Verification failures are generally treated as network failures. See "Error Recovery" below for the approach to dealing with loading errors and partially loaded apps.


== Security Restrictions ==
''Italic text''== Security Restrictions ==
* Only signed scripts may be loaded
* Only signed scripts may be loaded
* Only signed entry points can be navigated to
* Only signed entry points can be navigated to
*
* All privileged content must be served over a secure network connection.   
* All privileged content must be served over a secure network connection.   
* No framing privileged content
* No framing privileged content

Revision as of 05:35, 17 July 2015

Privileged Content

This page details implementation of signed privileged content for FxOS. The basic properties of privileged content is that:

  • they are enumerated in a manifest
  • signed to prevent modification
  • loaded into a unique origin which is granted special permissions(separate from other web content on the same domain)

Background: Packaged Content

bug 1036275 introduced packaged HTML content to Firefox. Packages must be served with "Content-Type: application/package" mime type.

An example of a regular package is shown below: 

--gc0pJq0M:08jU534c0p
Content-Location: /index.html
Content-Type: text/html

<html>
  <head>
    <script src="scripts/app.js"></script>
    ...
  </head>
  ...
</html>

--gc0pJq0M:08jU534c0p
Content-Location: /scripts/app.js
Content-Type: text/javascript

module Math from '/scripts/helpers/math.js';
...

--gc0pJq0M:08jU534c0p
Content-Location: /scripts/helpers/math.js
Content-Type: text/javascript

export function sum(nums) { ... }
...

--gc0pJq0M:08jU534c0p--

Privileged Packages

The Signed Manifest

A packaged is denoted by setting two packages headers. The first points to the manifest for the package (contains a list of files and digests of these files) and a signature of manifest content in JWS format: 

  manifest: /someapp.webmanifest
  manifest-signature: MRjdkly.... (Base64 JWS Signature over manifest content)

Package headers are specified by the w3c format and are headers which are sent inside the package, but prior to the first data part. Modifiying the above example, we get something like: 

manifest: /someapp.webmanifest
manifest-signature: MRjdkly.... (Base64 JWS Signature)
--gc0pJq0M:08jU534c0p
Content-Location: /someapp.webmanifest
Content-Type: application/manifest

{
"name": "My App", 
"description":"A great app!"
...

App Manifest Extensions

We add a resources section to the app manifest which enumerates content which needs to have integrity check. 

{
"name": "My App",
"scope": "/",
"start_url": "/index.html",
"permissions": [
  {
    "systemXHR": {
      "description": "Needed to download stuff"
    },
    "devicestorage:pictures": {
      "description": "Need to load pictures"
    }
  }
],
"resources": [
  {
    "src": "/index.html",
    "integrity": "sha256-kass...eoirW-e"
  },
  {
    "src": "/page2.html",
    "integrity": "sha256-kasguie...ngeW-e"
  },
  {
    "src": "/script.js",
    "integrity": "sha256-agjdia2...wgda"
  },
  {
    "src": "https://libraries.com/library.js",
     "integrity": "sha256-geijfi...ae3W"
  }
]
}


Processing Model

The normal loading process is:

  1. Gecko loads the manifest
  2. Gecko checks the signature of the manifest
  3. If signature verifies, a privileged child process is launched
  4. Web page is loaded as a normal web page inside this privileged process
  5. Although the _process_ is privileged, permission are restricted until verification is complete

The verification process is as follows:

  1. After the manifest signature checks out, gecko starts downloading all files enumerated in the manifest
  2. Each resource has is checked against a digest from the manifest
  3. If the integrity check passes, the resource is cached
  4. Once all the resources have been cached, only then is content considered privileged and permissions available to it

To update a privileged app:

2.2. Update

  1. GET manifest, If-Modified-Since
  2. Look for what files have changed, by addition/deletion/integrity
  3. Update changed files


Verification failures are generally treated as network failures. See "Error Recovery" below for the approach to dealing with loading errors and partially loaded apps.

Italic text== Security Restrictions ==

  • Only signed scripts may be loaded
  • Only signed entry points can be navigated to
  • All privileged content must be served over a secure network connection.
  • No framing privileged content
  • Resources enumerated in the manifest must have their integrity checked prior to loading

Note:

  • Not all HTML must be signed. There is little value in making this a firm requirement since it isn't possible to prevent dynamic HTML changes (this risk is unchanged from previous packaged approach)
  • Developers should be encouraged to sign all static resources)

New Headers

Instead of being installed, FxOS app content is navigated to. A http header is use to inform gecko that a web page belongs to an app:

manifest: https://app.foo.com/app/fooapp.webmanifest manifest-signature: https://app.foo.com/app/fooapp.sig


Loading an app

When an app-manifest is encountered, while the page is loaded as normal, additional steps are initiated in parallel. Two main processes are started: - populating cache with app enumerated resources - verification of signed resources and granting of permissions

Cache population

When gecko encounters an app manifest, resources

Verification of resources

Error Recovery

Retrieved from "https://wiki.mozilla.org/index.php?title=FirefoxOS/New_security_model/Packaging&oldid=1085290"