Closed Bug 1023499 Opened 10 years ago Closed 8 years ago

Provide mechanism to provision phones with an additional certificate for testing

Categories

(Core :: Security: PSM, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: ozten, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Background: A new project BetaFox[1] was relying on the same provisioning steps as the old "Installing Reviewer Certs"[2] procedure. This has been removed from FxOS and those certs are now baked into the device, eliminating the capability to add additional certs via adb.

Requirements:
* BetaFox is a self-hosted service which allows developers to distributed privileged apps for testing, before entering the Marketplace review queue
* Some mechanism which allows a user to provision a device as a beta testing device which trusts a deployed instance of BetaFox software
* A provisioned device should allow install of a privileged packaged app via the mozApps.installPackage API
* A provisioned device should launch installed privileged packaged apps signed by a BetaFox service
* A partner could self-host a BetaFox instance behind a corporate firewall
* A partner can generate their own certificate

Related Marketplace reviewer bugs: bug#896620 bug#1021345

[1] https://wiki.mozilla.org/Mobile/Projects/BetaFox
[2] https://wiki.mozilla.org/Marketplace/Reviewers/Apps/InstallingReviewerCerts
Blocks: 1004611
Flags: needinfo?(dkeeler)
Here's my understanding of the current consensus for how to go about this:

* Modify AppTrustDomain to handle additional specified trusted roots (in addition to those already built in)
* Modify Webapps.jsm to pick the appropriate root given that the user may have installed additional root certificate/install origin pairs
* Add UI for users to import and trust a root certificate for a given app install origin

I believe this would fulfill all requirements (and in particular the final one, that partners have the ability to generate their own certificates).

I'd like to propose an alternative that would be significantly less complex, require fewer implementation changes, and would be more likely to ship earlier. Instead of adding new roots (and implementing a UI to manage them), let's have all such development work use a single signing certificate with a well-known private key. All that would be necessary at that point would be to associate a development app install origin (or set of origins) with the well-known test root. This could be a string pref, which would make UI much simpler. Only when in development mode and only when the app install origin matches a specified origin would an app signed by this root verify correctly. All other app verification would work as expected.
I realize asking people to use a publicly-known private root seems strange, but unless I'm misunderstanding the use-cases, the guarantees/benefits from proper signing don't really apply here.
Flags: needinfo?(dkeeler)
> I'd like to propose an alternative that would be significantly less complex...

To restate this, to make sure I understand

* A new well known signing certificate would be created
* It's private key can be distributed to partners for installation on their app server
* If devices must be in development mode
* If preference must be set which includes the app server's endpoint as a trusted install origin
* Then device trusts configured 3rd party app server while still working with production Marketplace
* and optionally Marketplace review could also be enabled
(In reply to Austin King [:ozten] from comment #2)
> To restate this, to make sure I understand

Yes, I think we're on the same page.

> * and optionally Marketplace review could also be enabled

We could make these separate, if need be. The way I was thinking, they would both be enabled if the development mode was enabled.
If it isn't a substantial burden...

It would be ideal that we could have a device trust multiple certificates.

Use Case: I provision my phone to trust BetaFox, but it still allows me to install and launch apps signed by the marketplace.

Reasoning - This will allow community members to beta test on their main phone, without a dedicated "testing" phone.
Sure - I think a good approach would be to basically have a map of domain -> root certificate. marketplace.firefox.com would map to the root currently in use, marketplace-dev.allizom.org would map to the dev root in use, and testers/developers could add their own mapping of foocorp.example.com -> {foocorp certificate}. These should all be able to coexist without affecting installation from different domains.
(In reply to David Keeler (:keeler) [use needinfo?] from comment #5)
> Sure - I think a good approach would be to basically have a map of domain ->
> root certificate. marketplace.firefox.com would map to the root currently in
> use, marketplace-dev.allizom.org would map to the dev root in use, and
> testers/developers could add their own mapping of foocorp.example.com ->
> {foocorp certificate}. These should all be able to coexist without affecting
> installation from different domains.

Yes, we'll definitely need that kind of flexibility.
Quick hack of a patch attached, which adds provisions for a new "DevTest" root.  The idea is: 
* We publish the cert AND the private key that goes with it
* Developers could then sign their apps with the private key
* Developers/testers use some UI to enable the test root for a specific origin

With this patch, it seems like it should be possible to adapt the _openSignedPackage method in Webapps.jsm (which already changes the root used for verification) to enable the test root for specific origins.

Still TODO: Figure out when apps should be verified with the test cert, and how to prevent this from becoming a huge security hole.  Also, tests.

Austin, Fabrice: Does this look like a reasonable starting point?
Flags: needinfo?(ozten.bugs)
Flags: needinfo?(fabrice)
With the given caveats, this LGTM.

We should make it built in to:

* Authorize betachannel.mozilla.org to use DevTest

We should make it possible to:

* Add additional origins as "Distribution Channels" which would also use DevTest

These points are mentioned in Bug#1012705
Blocks: 1012705
That sounds reasonable to me. I can help with the Webapps.jsm changes if needed.
Flags: needinfo?(fabrice)
Great.  I'm going to consider my work here done for the moment :)

Please circle back once you guys have an idea of how you're going to enable use of DevTest.  I'm very concerned about this being a vector for circumventing app signing.  I would be glad to review patches.
Flags: needinfo?(ozten.bugs)
Is this still needed?
Flags: needinfo?(ozten.bugs)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: