Closed Bug 915067 Opened 11 years ago Closed 11 years ago

Block access to certified apps by default

Categories

(DevTools Graveyard :: WebIDE, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 26

People

(Reporter: paul, Assigned: jryans)

References

Details

Attachments

(2 files, 1 obsolete file)

We don't want people to be able to enable remote debugging and then dig into the certified app and extract sensitive data. To address this, we will implement another remote debugging button that will destroy sensitive data. The plan is: 1. in the settings app, we add a new item, named "enable system debugging". Enabling this setting will delete any sensitive data from the data. A prompt will first ask the user if he's sure he wants to do that. 2. wiping will: - empty indexeddb - empty localstore - delete cookies 3. the webapps actor will filter out certified apps if "enable system debugging" is not activated
Blocks: appmgr_v1
One thing that occurred to me was can we just leverage the existing 'factory reset' code in the settings app to perform this wipe?
Factory reset may be too extreme though - just check with the platform tea,, and that delete all apps that are not certified apps, and also clears the data in the certified apps.
Factory reset erases everything (apps, prefs, ...). We only want to delete sensitive data.
(In reply to Paul Theriault [:pauljt] from comment #2) > Factory reset may be too extreme though - just check with the platform tea,, > and that delete all apps that are not certified apps, and also clears the > data in the certified apps. Even worse, it will clear chrome related indexedDB storage, like activities, and we need to keep some of these around.
Fabrice will introduce a new pref, called `devtools.debugger.forbid-certified-app`. Which will be false "true" by default. Once wipe has been done, it will be false.
"Which will be "true" by default."
I'll be working on the actor change (part 3 from comment #0) here. Is filtering out certified apps sufficient? Or do we need to also block signed apps from the Marketplace?
Flags: needinfo?(ptheriault)
Does a production device allow someone to write to prefs.js in their profile via adb shell? If it does, then it would be possible to flip this new pref without first wiping the data.
This adds the default value of the pref. I used the plural version, since that seemed clearer to me, so that makes it "devtools.debugger.forbid-certified-apps".
Attachment #803367 - Flags: review?(poirot.alex)
(In reply to J. Ryan Stinnett [:jryans] from comment #8) > Does a production device allow someone to write to prefs.js in their profile > via adb shell? If it does, then it would be possible to flip this new pref > without first wiping the data. No that's not possible on production devices. But, after doing some initial implementation on the gecko side I think we should not do that. I can't even wipe most of the core apps because that makes them unusable (eg, wiping the indexedDB of the homescreen app is not a good idea). We'll discuss again tomorrow...
This filters several of the webapps actor's messages when certified apps are forbidden: * getAll * listRunningApps * getAppActor * appOpen * appClose Other actions are left unfiltered because they did not seem like a security concern.
Attachment #803374 - Flags: review?(poirot.alex)
To me it would be more ideal if (In reply to J. Ryan Stinnett [:jryans] from comment #7) > I'll be working on the actor change (part 3 from comment #0) here. > > Is filtering out certified apps sufficient? Or do we need to also block > signed apps from the Marketplace? I think certified is ok for the moment. My personal preference is that we wipe sensitive data for all apps, so that we protect data stored in any app. But that impacts the usability of the feature, so we decided to compromise on certified apps. Certified apps are more important since they have access to permissions which can impact the integrity of the phone, or directly cost the user money. Privileged permissions generally can't do this.
Flags: needinfo?(ptheriault)
Comment on attachment 803367 [details] [diff] [review] Part 1: Add pref to block debugging certified apps Review of attachment 803367 [details] [diff] [review]: ----------------------------------------------------------------- Please rebase your patch, it doesn't seem to apply with last changeset.
Attachment #803367 - Flags: review?(poirot.alex) → review+
Comment on attachment 803374 [details] [diff] [review] Part 2: Filter certified apps from webapps actor Review of attachment 803374 [details] [diff] [review]: ----------------------------------------------------------------- Looks good and works fine! ::: toolkit/devtools/server/actors/webapps.js @@ +521,5 @@ > > return defer.promise; > }, > > + _areCertifiedAppsAllowed: function wa__areCertifiedAppsAllowed() { Here and other new methods, we no longer add function name to new methods of the webapps actor, as devtools now play nice with stack involving anonymous functions.
Attachment #803374 - Flags: review?(poirot.alex) → review+
Rebased. Carrying over Alex's r+ from attachment #803367 [details] [diff] [review].
Attachment #803367 - Attachment is obsolete: true
Attachment #804039 - Flags: review+
Assignee: nobody → jryans
Status: NEW → ASSIGNED
We've agreed via email to just block debugging via this pref for 1.2, with no UI to change it. This is unfortunate, but hopefully we can improve this in future versions. Fabrice has added sideloading of certified apps in bug 915881.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 26
Summary: wipe sensitive data on system debugging → Block access to certified apps by default
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: