Security/Reviews/Packaged Apps
Item Reviewed
| Packaged Apps: Signing & Revocation | |||||||||||||
| Target |
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=
| 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?)
|
|
{{#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?)
}}