Security/Reviews/Packaged Apps

From MozillaWiki
Jump to navigation Jump to search
Please use "Edit with form" above to edit this page.

Item Reviewed

Packaged Apps: Signing & Revocation
Target
   
     Full Query    
   
ID Summary Priority Status
772365 Implement signing mechanism for packaged apps P1 VERIFIED
816282 SecReview: Implement signing mechanism for packaged apps P1 RESOLVED

2 Total; 0 Open (0%); 1 Resolved (50%); 1 Verified (50%);

Spec document: https://wiki.mozilla.org/Apps/PrivilegedApplication/SigningService

{{#set:SecReview name=Packaged Apps: Signing & Revocation

|SecReview target=

Full Query
ID Summary Priority Status
772365 Implement signing mechanism for packaged apps P1 VERIFIED
816282 SecReview: Implement signing mechanism for packaged apps P1 RESOLVED

2 Total; 0 Open (0%); 1 Resolved (50%); 1 Verified (50%);

Spec document: https://wiki.mozilla.org/Apps/PrivilegedApplication/SigningService }}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

  • reuse xpi signing for apps in B2G
    • same bits we are using for signing receipts

Signing parts:

  • Server Side
    • How do we control signing (access to signing machine)?
    • How do we deal with multiple signing (signing many apps) Is it manual?
      • Marketplace
      • Client

Reviewers get/generate a test cert

  • tool to install cert into the phone
  • tool to sign using that cert
  • after review the reviewer-signed app is sent to marketplace
  • marketplace verifies reviewer's signature and logs who signed which app
  • marketplace re-signs the app and puts it in the store.

Install:

  • download zip
  • check signature
  • if no sig max privilege is "installed"
  • if there's a valid signature max priv is "trusted"
  • if the signature is invalid the app is not installed
  • process manifest requested permissions limited by max priv
  • signature never used again until we update that app

What solutions/approaches were considered other than the proposed solution?

`

Why was this solution chosen?

`

Any security threats already considered in the design and why?

`

Threat Brainstorming

  • Receipts signing certs were rotated to avoid people signing receipts for ever. What happens if someone gets access to the certs? Do we have a plan for revocation?
    • re-sign all the apps
    • push a firmware update to revoke the cert

{{#set: SecReview feature goal=* reuse xpi signing for apps in B2G

    • same bits we are using for signing receipts

Signing parts:

  • Server Side
    • How do we control signing (access to signing machine)?
    • How do we deal with multiple signing (signing many apps) Is it manual?
      • Marketplace
      • Client

Reviewers get/generate a test cert

  • tool to install cert into the phone
  • tool to sign using that cert
  • after review the reviewer-signed app is sent to marketplace
  • marketplace verifies reviewer's signature and logs who signed which app
  • marketplace re-signs the app and puts it in the store.

Install:

  • download zip
  • check signature
  • if no sig max privilege is "installed"
  • if there's a valid signature max priv is "trusted"
  • if the signature is invalid the app is not installed
  • process manifest requested permissions limited by max priv
  • signature never used again until we update that app

|SecReview alt solutions=' |SecReview solution chosen=' |SecReview threats considered=' |SecReview threat brainstorming=* Receipts signing certs were rotated to avoid people signing receipts for ever. What happens if someone gets access to the certs? Do we have a plan for revocation?

    • re-sign all the apps
    • push a firmware update to revoke the cert

}}

Action Items

Action Item Status In Progress
Release Target `
Action Items
* Our app "revocation" seems to depend on the app coming from the marketplace (not simply being signed by the marketplace). Nothing at the moment seems to stop a web-site from installing a copy of a marketplace-signed privileged app. (is that a problem?)
  • Marketplace team: Add a link to the mini-manifest inside the packaged. (Merge into bug 814131?)
  • Platform team (bsmith): require that mini-manifest link inside the signed JAR and make sure that the mini-manifest inside the JAR overrides the original (download) mini-manifest URI. (Merge into bug 814136?)

{{#set:|SecReview action item status=In Progress

|Feature version=` |SecReview action items=* Our app "revocation" seems to depend on the app coming from the marketplace (not simply being signed by the marketplace). Nothing at the moment seems to stop a web-site from installing a copy of a marketplace-signed privileged app. (is that a problem?)

  • Marketplace team: Add a link to the mini-manifest inside the packaged. (Merge into bug 814131?)
  • Platform team (bsmith): require that mini-manifest link inside the signed JAR and make sure that the mini-manifest inside the JAR overrides the original (download) mini-manifest URI. (Merge into bug 814136?)

}}