Closed Bug 813797 Opened 8 years ago Closed 8 years ago

Completely remove apps developer mode (dom.mozApps.dev_mode) in release builds

Categories

(Firefox OS Graveyard :: General, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18 fixed)

RESOLVED FIXED
B2G C4 (2jan on)
blocking-basecamp +
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 --- fixed

People

(Reporter: amac, Assigned: ochameau)

References

Details

(Whiteboard: [qa-])

Attachments

(1 file)

Developer mode as it's currently implemented is too dangerous and there's no clear indication of that to the developer, nor any mitigation measure.

Currently, when dom.mozApps.dev_mode is set to true, the normal enforcement of application types (certified == preinstalled only, privileged==signed from a trusted source) is completely overridden. It also allows hosted apps (web apps in other words) to declare themselves as privileged or certified. While this allows developers a great flexibility for testing and developing their apps it also makes the device total, complete, and absolutely unsuitable for normal use. 

While dev_mode is active any web app the device navigates to can declare itself as certified, require all the permissions on its manifest and do whatever it pleases on the device. Without the developer being none the wiser. Note that this isn't evident even to a developer. 

If there's no time to put some mitigation measures in place for V1, at least the settings app should give a BIG warning about this when setting this preference. And probably ask for confirmation again after the warning.
The right mitigation probably to fix this is at the settings app level probably - we need to explicitly give probably an equivalent "scary" warning that you would see if you enabled unknown sources on an Android device. That would probably mitigate the concern you are bringing.
blocking-basecamp: --- → ?
Component: General → Gaia::Settings
The UI and this setting and the code that honors it (wherever it may be) needs to disappear entirely in release builds.  If that looks the least bit nontrivial, then this mode should disappear entirely.
Summary: Apps developer mode (dom.mozApps.dev_mode) is too dangerous as it stands → Completely remove apps developer mode (dom.mozApps.dev_mode) in release builds
(In reply to Chris Jones [:cjones] [:warhammer] from comment #2)
> The UI and this setting and the code that honors it (wherever it may be)
> needs to disappear entirely in release builds.  If that looks the least bit
> nontrivial, then this mode should disappear entirely.

So how exactly are developers supposed to developer privileged apps for our platform then? That was the point of the preference in the first place.
(In reply to Jason Smith [:jsmith] from comment #3)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #2)
> > The UI and this setting and the code that honors it (wherever it may be)
> > needs to disappear entirely in release builds.  If that looks the least bit
> > nontrivial, then this mode should disappear entirely.
> 
> So how exactly are developers supposed to developer privileged apps for our
> platform then? That was the point of the preference in the first place.

Note - this is the documented workflow for app developers right now to use this preference.

See https://developer.mozilla.org/en-US/docs/Apps/Packaged_apps
We need to keep our priorities straight: we're talking about a small convenience for a small number of app developers versus a giant gaping security hole for millions and millions of users.  The latter group always trumps the former.

So what we need to do first is identify the use cases for "developer mode" with privileged apps.  Privileged apps are just supposed to be able to skip permission prompts.  Being able to bypass that during dev is not an important use case to me at all.

What are the use cases?

Note, third-party developers can't deliver certified apps through the marketplace (by definition), so certified apps aren't a use case.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> We need to keep our priorities straight: we're talking about a small
> convenience for a small number of app developers versus a giant gaping
> security hole for millions and millions of users.  The latter group always
> trumps the former.

Not exactly. If you don't have an avenue to actually be able to build privileged apps, then the security benefit doesn't do any value - cause you won't have anyone building the apps in the first place.

Fabrice had a proposal in IRC that compromise the two points however:

	fabrice	another way to provide this functionnality would be to create a new permission, and grant that to an "developer app install store". From this dev store, we would relax the checks like the pref does now

We need to balance keeping the developer experience for building privileged apps possible (and reasonable) while balancing the security concerns. But going to one extreme here I don't think is an option to consider.

> 
> So what we need to do first is identify the use cases for "developer mode"
> with privileged apps.  Privileged apps are just supposed to be able to skip
> permission prompts.  Being able to bypass that during dev is not an
> important use case to me at all.

No, that's not the intention. The original intention for the developer mode was to get access to WebAPIs that typically hosted content does not get access to, so that a developer can build and test against those APIs directly if they are building apps requiring a higher trust level.

> Note, third-party developers can't deliver certified apps through the
> marketplace (by definition), so certified apps aren't a use case.

Not through the marketplace, but we do have apps being built to be preloaded on the phone by external developers. I don't have knowledge of any of them building preloaded apps for v1 that would require certified access though, but that's not saying this could happen in the future.

Jonas - Do you have an opinion here?
Component: Gaia::Settings → General
Flags: needinfo?(jonas)
Note that some gaia developers use this mode to access privileged APIs in gaia DEBUG mode.
It's hard to extract clear use cases from comment 6.  Please, let's keep this as concrete as possible: "Developer in situation X is trying to develop app that does Y in development environment Z."

I see a clear use case in comment 7.  Gaia DEBUG mode implies non-release build, so I don't see why having this setting available in release builds is necessary.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #8)
> It's hard to extract clear use cases from comment 6.  Please, let's keep
> this as concrete as possible: "Developer in situation X is trying to develop
> app that does Y in development environment Z."

Okay, I'll be more explicit:

1. A third-party app developer is trying to build a browser packaged app that can ran on FF OS that makes use of the browser API.

Implications - browser API in the permissions matrix is listed a privileged API, so a web developer would need a way to test their use of the browser API is indeed correct in a packaged app. The development environment I guess in this case would be a desktop build using the FF OS simulator, as that's the currently advertised route we could point app developers at.

2. A third-party app developer is trying to build an alternative contacts management app for FF OS that makes use of the contacts API

Implications - similar implications as stated above except with the contacts api, except probably in this case, I'm not how effective a desktop build would prove value for testing against the contacts api, given that a real phone would give the true situation.

3. A third-party app developer is trying to build a web app that takes advantage of device storage on FF OS - thus making use of the device storage web api

Implications - similar implications as stated above except with the device storage api. This api in particular is probably even more so important that the app developer has an avneue to be able to directly test this on device.

And so on with each privileged or higher webapi.

Perhaps a possible mitigation is that the developer would have to go through some marketplace flow to be able to test the privileged app before submission. Although that's something to think about on what the right third-party app developer flow is for building a packaged app making use of privileged apis.
(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #8)
> > It's hard to extract clear use cases from comment 6.  Please, let's keep
> > this as concrete as possible: "Developer in situation X is trying to develop
> > app that does Y in development environment Z."
> 
> Okay, I'll be more explicit:
> 
> 1. A third-party app developer is trying to build a browser packaged app
> that can ran on FF OS that makes use of the browser API.

That's a certified API in v1 because of platform limitations.

> 2. A third-party app developer is trying to build an alternative contacts
> management app for FF OS that makes use of the contacts API
> 
> Implications - similar implications as stated above except with the contacts
> api, except probably in this case, I'm not how effective a desktop build
> would prove value for testing against the contacts api, given that a real
> phone would give the true situation.

The b2g-desktop implementation of contacts is the same as on the phone.

Let's say for the sake of argument that testing on b2g-desktop isn't sufficient.  Why can't this developer test with a custom b2g or gaia build?

> 
> 3. A third-party app developer is trying to build a web app that takes
> advantage of device storage on FF OS - thus making use of the device storage
> web api
> 
> Implications - similar implications as stated above except with the device
> storage api. This api in particular is probably even more so important that
> the app developer has an avneue to be able to directly test this on device.

Media storage is implemented pretty much the same way on desktop-b2g for Tier Is as on the phone.

But let's say again that that's not sufficient.  Media storage will prompt the user when apps that haven't already been granted access try to use it.  (Last time I tried.)  Why can't the developer test her app after permanently granting media-storage to her test app the first time?
To be honest, I'm with Chris on this one. Dev mode permissions right now are too broad. A better solution to allow on-device testing of privileged apps (certified apps is another story, and they should require a custom build of the device, since anyway they cannot be distributed without a device right now) would be to implement some way to add a developer-chosen certificate to the device, and make the package generation and signing tools public. 

In fact, IIRC, one of the reasons the signed jar was chosen as a format for the packaged apps was that it was a format already known and familiar to Android developers. 

In this way, dev_mode flag would just allow custom CA certificates --and setting of the reportOnly mode for CSPs, see bug 801783. And a developer that wanted to develop and test privileged apps would:

* Set the dev_mode flag to true, and import (on the same screen) his developer certificate/custom CA certificate.
* Develop his app. 
* Sign it with his certificate and the provided tools. 
* Install the app on the device

This way he can test privileged apps without adding too much risk (besides losing control of his own certificate, that is :) ).
Antonio - That sounds reasonable to me.

cc-ing a bunch of marketplace folks for input as well
(In reply to Antonio Manuel Amaya Calvo from comment #11)
> now) would be to implement some way to add a developer-chosen certificate to
> the device, and make the package generation and signing tools public. 

I like the sounds of this.

It sounds similar to another use case I was curious about... how Marketplace reviewers will be able to install apps that aren't yet approved or public so they can review them on device. With this, it sounds like it might be possible to sign packages with a separate reviewers-only cert that is installed on their devices.

Re: make the signing tools public. Do you mean for the devs to install the software on their own machines to be able to sign packages? Or do you mean that Marketplace might offer a service to sign packages with the provided certificate? And possibly also offer to generate that certificate? I can see that would remove a lot of barriers. CC'ing Andy and Ryan if that's a possibility with our signing service.
(In reply to Rob Hudson [:robhudson] from comment #13)
> Re: make the signing tools public. Do you mean for the devs to install the
> software on their own machines to be able to sign packages? Or do you mean
> that Marketplace might offer a service to sign packages with the provided
> certificate? And possibly also offer to generate that certificate? I can see
> that would remove a lot of barriers. CC'ing Andy and Ryan if that's a
> possibility with our signing service.

I was actually referring to the first case (just packaging the signing tools and distributing them). The second one also has entrance barriers, only different ones. On the first case (distributed tools), I just download a package and I can develop to my heart's wish without depending on anyone or registering anywhere. On the second case (tools as a service) I would have to register on some marketplace just to test my apps. 

In any case, and if it's an option, I think the best would be to do both: give the toolset for those that don't want to register before they have to, and give a signing service for those that just want to code HTML5 and don't want to know anything about certificates, signing tools and package formats.
Okay, sounds like this bug in it's current state is an okay direction to go. We should file followups though for making sure the developer flow for privileged apps is still possible. Rob - Do you want to file the bugs in the appropriate spots?
Flags: needinfo?(jonas)
blocking-basecamp: ? → +
I agree that dev mode is too broad right now, but what it does is really useful. Actually, what I would prefer from the app developer POV would be if, when dev mode is activated in the settings, an app that states a priviledged or certified level would trigger a scary warning on first launch where the user can grant or deny this privilege escalation on a per-app level.
It's extremely helpful to have a mode where you can incrementally test and develop your app without packaging or signing - but it should be restricted to those app you actually do develop.
Flags: needinfo?(jonas)
Assigning to Jonas to make a decision.
Assignee: nobody → jonas
Flags: needinfo?(jonas)
Setting priority based on triage discussions.  Feel free to decrease priority if you disagree.
Priority: -- → P1
I'm not sure we should remove it so much as remove the UI, but still allow it to be set via ADB.  Ideally we'd have a test certificate the developer could generate & import, but I'm not sure we'll have time to implement that for basecamp.
(In reply to Lucas Adamski from comment #19)
> I'm not sure we should remove it so much as remove the UI, but still allow
> it to be set via ADB.  Ideally we'd have a test certificate the developer
> could generate & import, but I'm not sure we'll have time to implement that
> for basecamp.

So, what should we do for v1? I can take it, but there's no clear decision here.
Flags: needinfo?(jonas)
Progress ping, + cc bsmith.

If we let developers install a certificate, would this solve the issue for packaged apps? We would still regress the situation for developers that use gaia in DEBUG mode (serving apps over http) to work on certified apps.
Target Milestone: --- → B2G C3 (12dec-1jan)
Why not just turn off the big switch in the UI, but still allow this switch to be set when flashing a phone with a DEBUG gaia checkout?

Pretty much what Lucas suggests in comment 19.

The big switch in the ui is definitely too dangerous to leave in release builds, and it won't be needed for 99% of developers anyway.

(I have never once used it while working on b2g)
(In reply to Fabrice Desré [:fabrice] from comment #21)
> Progress ping, + cc bsmith.
> 
> If we let developers install a certificate, would this solve the issue for
> packaged apps? We would still regress the situation for developers that use
> gaia in DEBUG mode (serving apps over http) to work on certified apps.

My concern is that they will then have to generate the cert and then sign each iteration of their app during their code/build/deploy/test cycle. How would we handle the tooling for that?

I really like the idea of using the remote debugger protocol to push the test app to the phone. If we do that then I don't think any signing is needed--we can just say that any app installed by the debugger can be privileged.
Update:  Jonas told me on IRC that he and bsmith have a plan which they're going to confirm.
Flags: needinfo?(jonas)
Jonas, Bsmith - any update on the plan?
Some things we should clear up, up front
 - we can't ship a production phone with root shell enabled.  That completely obliterates our OS-level security.
 - the current debugging socket, while slightly better than root shell because it requires users to opt-in, is still a security hole you could drive a truck through (in current implementation).  Leaving it enable-able in production (in current implementation) would drop us below parity with competing OSes.

We have two baseline solutions to this problem.  One is to encourage developers to use the emulator.  This is less than ideal as things stand now because moz can't redistribute our emulator builds, but this is fixable off the critical path to ship.  The second is to have developers of privileged apps unlock their phones and flash custom builds without production-level security.  I agree that this sucks.

Has anyone thought through the workflow for developers of privileged apps?  I agree with comment 23, but some part of the workflow will involve packaging and manifest generation, so maybe the tooling framework will be there anyway.  This doesn't solve the shift-reload development case though, which isn't ideal.  Adding support for installing third-party certs is also rather nontrivial.

Here's a strawman proposal to cover all the use cases
 - have "developer" mode enable adb and have the b2g process create a special "developer" UNIX-domain socket
 - make an |install| script or binary that takes a path to a manifest
 - have |install| connect() to the "developer" socket and initiate an install request
 - b2g checks that the request comes from either the shell or root user, and if the check passes installs the manifest with privileged status

The manifest can point wherever the user wishes, including http://[my-local-server-ip] or file:///data/local/tmp/application.zip.

This allows "drive-by" installs of privileged apps, but only from users with physical control of a phone.  The mechanism used to install development apps doesn't create security holes beyond that risk, and doesn't expose user data.
Bill Maggs I believe is driving the developer workflow for privileged apps. Adding him for input.
Flags: needinfo?(wmaggs)
Target Milestone: B2G C3 (12dec-1jan) → B2G C4 (2jan on)
(In reply to Chris Jones [:cjones] [:warhammer] from comment #26)
> Some things we should clear up, up front
>  - we can't ship a production phone with root shell enabled.  That
> completely obliterates our OS-level security.

Please provide more details. What do you mean by "completely obliterates"? Why is it the case that running adb shell as root causes that?

Is it "just" that anyone with physical access to the device can completely take over the device? Or does running adb shell as root make it easier for apps to hack the device somehow?

> We have two baseline solutions to this problem.  One is to encourage
> developers to use the emulator.  This is less than ideal as things stand now
> because moz can't redistribute our emulator builds, but this is fixable off
> the critical path to ship.

The emulator doesn't allow testing multi-touch. It also doesn't allow you to test the performance of real hardware. And I would personally not want to ship software that has never been tested on the target hardware, no matter how good someone claims the emulator is.

> The second is to have developers of privileged
> apps unlock their phones and flash custom builds without production-level
> security.  I agree that this sucks.

A lot of the discussion here also applies to app reviewers since they need to get a reviewer certificate onto the device. The higher we make the bar for reviewers to review applications, the harder time we'll have at getting reviewers and the longer the backlog will be in the marketplace.

But yes. I do agree that we need to keep this as an option.

> Here's a strawman proposal to cover all the use cases
>  - have "developer" mode enable adb and have the b2g process create a
> special "developer" UNIX-domain socket
>  - make an |install| script or binary that takes a path to a manifest
>  - have |install| connect() to the "developer" socket and initiate an
> install request
>  - b2g checks that the request comes from either the shell or root user, and
> if the check passes installs the manifest with privileged status

Basically this sounds like "be safe by default, but have a UI switch which enables unsafe mode". Which sounds ok with me.
(In reply to Jonas Sicking (:sicking) from comment #28)
> (In reply to Chris Jones [:cjones] [:warhammer] from comment #26)
> > Some things we should clear up, up front
> >  - we can't ship a production phone with root shell enabled.  That
> > completely obliterates our OS-level security.
> 
> Please provide more details. What do you mean by "completely obliterates"?
> Why is it the case that running adb shell as root causes that?
> 
> Is it "just" that anyone with physical access to the device can completely
> take over the device? Or does running adb shell as root make it easier for
> apps to hack the device somehow?

It means that anyone with physical access can completely pwn, and it means that the interfaces exposed through adbd allow privilege escalation to root if compromised, and those interfaces aren't hardened to run as root in production builds.

> 
> > We have two baseline solutions to this problem.  One is to encourage
> > developers to use the emulator.  This is less than ideal as things stand now
> > because moz can't redistribute our emulator builds, but this is fixable off
> > the critical path to ship.
> 
> The emulator doesn't allow testing multi-touch. It also doesn't allow you to
> test the performance of real hardware. And I would personally not want to
> ship software that has never been tested on the target hardware, no matter
> how good someone claims the emulator is.

I agree, however as a primary development target the emulator is awesome.

> > Here's a strawman proposal to cover all the use cases
> >  - have "developer" mode enable adb and have the b2g process create a
> > special "developer" UNIX-domain socket
> >  - make an |install| script or binary that takes a path to a manifest
> >  - have |install| connect() to the "developer" socket and initiate an
> > install request
> >  - b2g checks that the request comes from either the shell or root user, and
> > if the check passes installs the manifest with privileged status
> 
> Basically this sounds like "be safe by default, but have a UI switch which
> enables unsafe mode". Which sounds ok with me.

We need to be more specific about what "unsafe" means.  There are three threats we're discussing here
 1. "unsafe" mode compromised to install malicious unsigned privileged apps
 2. "unsafe" mode exploited for drive-by pwnage of device and/or user personal data
 3. "unsafe" mode opens additional privilege escalation attacks for content processes

What I'm proposing is a mechanism that's not vulnerable to (2) and is easily securable against (1) and (3) (following established practices).
sicking, bsmith we need to agree on a plan stat.  Let's try to chat today.
(In reply to Jason Smith [:jsmith] from comment #27)
> Bill Maggs I believe is driving the developer workflow for privileged apps.
> Adding him for input.

All, 

As I am out of the country this week and you guys absolutely need to close on this, I would propose that the developer workflow considerations you asked me about can be covered by Daniel Buchner who is the PM of DevHub.

In general, approach above (Comment 26)  is probably the best we can do right now to balance developer and consumer needs given our platform's design. 

The workflow for privileged apps will start far from perfect but get better over time. 




(In reply to Jason Smith [:jsmith] from comment #27)
> Bill Maggs I believe is driving the developer workflow for privileged apps.
> Adding him for input.
Flags: needinfo?(wmaggs) → needinfo?(dbuchner)
Agree. We need to have fabrice there though since he's done work on one of the potential solutions. He's arriving later today.
/me looking
Assignee: jonas → poirot.alex
Blocks: 828288
Do we need a reviewer on this patch?
Comment on attachment 699852 [details] [diff] [review]
Bug 813797 - Completely remove apps developer mode (dom.mozApps.dev_mode) in release builds

I was trying to run tests before asking review. I finally managed to run the correct ones and webapps tests pass.
Attachment #699852 - Flags: review?(fabrice)
Attachment #699852 - Flags: review?(fabrice) → review+
Keywords: checkin-needed
Flags: needinfo?(dbuchner)
Whiteboard: [qa-]
Is there any suggested workflow to test and develop a certified app?

I am trying to develop a simple camera app with the invocation of navigator.mozGetUserMedia() and storing the pictures to sdcard with the device storage mechanism.
For now I am not able to do this, either on my device nor in the simulator, because I'm not allowed to grant the permissions for a certified app for testing purposes.
(In reply to aldipower from comment #39)
> Is there any suggested workflow to test and develop a certified app?

Using Simulator you can install privileged apps, permissions are granted by default. The whole flow is described at: https://hacks.mozilla.org/2013/03/how-to-install-packaged-apps-in-firefox-os-options-and-tools/

Keep in mind that WebRTC with getUserMedia hasn't landed yet on B2G 1.0 or 1.1. You might want to use Web Activities to get a picture from the camera for now.
You need to log in before you can comment on or make changes to this bug.