Add ability to disallow installation of any addon by non-admin user

VERIFIED FIXED in Firefox 60

Status

()

VERIFIED FIXED
2 years ago
6 months ago

People

(Reporter: yuki, Assigned: mkaply)

Tracking

(Blocks: 1 bug)

Trunk
mozilla60
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox60 verified, firefox61 verified)

Details

(Whiteboard: [design-decision-denied]triaged)

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
For enterprise use, the system administrator wants to disallow installing of any extra addon by users. With MCD (Mission Control Desktop), `lockPref("xpinstall.enabled", false)` prevents it for most cases, but drag-and-drop of XPI files onto about:addons page still available. Currently we can prevent it by disabling of about:addons page itself by something XUL-based addon, but after XUL is ended we need something to alter it.

The bug 1243357 says that xpinstall.enabled=false does not mean this. Thus something new one to do this is required.
(Reporter)

Updated

2 years ago
Blocks: 720362

Updated

2 years ago
Whiteboard: [design-decision-needed]triaged

Comment 1

2 years ago
We don't plan on this API in WebExtensions. Moving over to Firefox to see if that's something that would happen through configuration of other means.
Component: WebExtensions: Untriaged → General
Product: Toolkit → Firefox
Whiteboard: [design-decision-needed]triaged → [design-decision-denied]triaged

Updated

2 years ago
Component: General → Add-ons Manager
Product: Firefox → Toolkit
(Reporter)

Comment 3

a year ago
Now I change the summary to represent the most important topic.

As described at my first description, the well-known method to disallow installation of addons by non-admin user is `lockPref("xpinstall.enabled", false)`, but it just prevents to install addons from the Web and still there are backdoors:

 * Drag-and-drop of a XPI file onto about:addons page.
 * Put a XPI file into %AppData%/Mozilla/Firefox/Profiles/xxxx.default/extensions/
 * Put a XPI file into %appdata%/Mozilla/Extensions/

The easiest way to disallow them seems: removing "1" and "2" from "extensions.enabledScopes",
https://developer.mozilla.org/en-US/Add-ons/Installing_extensions#Disabling_install_locations
but it doesn't work as expected. Comments at the bug 591921 said that the value "1" is just a placeholder and user-installed addons are always activated. Actually the code also says same thing:
https://dxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/internal/XPIProvider.jsm#2112

As the result, enterprise administrator has no way to prevent non-admin users to install addons. After XUL is ended, this is serious problem for me (and my customer), and I'm finding any available solution except custom build.
Summary: Add ability to prevent installation of new addons by the user via drag and drop of XPI onto about:addons page → Add ability to disallow installation of any addon by non-admin user

Updated

a year ago
Duplicate of this bug: 1403886

Comment 5

10 months ago
(In reply to YUKI "Piro" Hiroshi from comment #3)
>  * Drag-and-drop of a XPI file onto about:addons page.
>  * Put a XPI file into
> %AppData%/Mozilla/Firefox/Profiles/xxxx.default/extensions/
>  * Put a XPI file into %appdata%/Mozilla/Extensions/

To add to that list:

 * `about:addons` -> `Extensions` -> Engine menu -> `Install Add-on From File`

A very similar bug was fixed here

https://bugzilla.mozilla.org/show_bug.cgi?id=815120
Comment hidden (mozreview-request)
(Assignee)

Comment 7

7 months ago
My patch ties in with bug 1429131 for the policy engine.

When xpinstall.enabled is false and locked, we assume it was done by an administrator. In that case, these two options should not be available.

Handling add-on installing via the file system is a completely different problem that I will not address.

If an administrator tries to lock down Firefox but still allows access to the file system, that's their problem to worry about.
(Assignee)

Updated

7 months ago
Blocks: 1429131

Comment 8

7 months ago
mozreview-review
Comment on attachment 8956122 [details]
Bug 1269294 - Prevent add-on install from add-ons manager if xpinstall disabled and locked.

https://reviewboard.mozilla.org/r/225054/#review231142

r=me with comments addressed.
As discussed on IRC, this preference still doesn't actually cover all the possible methods of installing addons.

::: toolkit/mozapps/extensions/content/extensions.js:167
(Diff revision 1)
> +  if (!Services.prefs.getBoolPref(PREF_XPI_ENABLED, true) &&
> +      Services.prefs.prefIsLocked("xpinstall.enabled")) {

Please make a common function for this.  Also lets use the symbolic constant consistently.

::: toolkit/mozapps/extensions/content/extensions.js:169
(Diff revision 1)
>    Services.obs.addObserver(sendEMPong, "EM-ping");
>    Services.obs.notifyObservers(window, "EM-loaded");
>  
> +  if (!Services.prefs.getBoolPref(PREF_XPI_ENABLED, true) &&
> +      Services.prefs.prefIsLocked("xpinstall.enabled")) {
> +    document.getElementById("cmd_installFromFile").hidden = true;

Please also return false from `cmd_installFromFile.isEnabled()`.
Attachment #8956122 - Flags: review?(aswan) → review+

Comment 9

7 months ago
mozreview-review
Comment on attachment 8956122 [details]
Bug 1269294 - Prevent add-on install from add-ons manager if xpinstall disabled and locked.

https://reviewboard.mozilla.org/r/225054/#review231156

::: toolkit/mozapps/extensions/content/extensions.js:168
(Diff revision 1)
>    gEventManager.initialize();
>    Services.obs.addObserver(sendEMPong, "EM-ping");
>    Services.obs.notifyObservers(window, "EM-loaded");
>  
> +  if (!Services.prefs.getBoolPref(PREF_XPI_ENABLED, true) &&
> +      Services.prefs.prefIsLocked("xpinstall.enabled")) {

Wait somehow I glossed over this before.  Why wouldn't we honor this preference if it is set to false but not locked?
(Assignee)

Comment 10

7 months ago
(In reply to Andrew Swan [:aswan] from comment #9)
> Wait somehow I glossed over this before.  Why wouldn't we honor this
> preference if it is set to false but not locked?

Setting xpinstall.enabled to false doesn't really have any real purpose. If you set it to false and then try to install an add-on, we allow you to turn it back on in the popup.

It's only by setting xpinstall.enabled to false and locking it that you can actually turn off xpinstall.

I could just turn this off with false if you'd like; it wouldn't do any harm.

Comment 11

7 months ago
(In reply to Mike Kaply [:mkaply] from comment #10)
> Setting xpinstall.enabled to false doesn't really have any real purpose. If
> you set it to false and then try to install an add-on, we allow you to turn
> it back on in the popup.

What popup?  We show popups for installs that come from the web but not for "install from file" or drag-and-drop
(Assignee)

Comment 12

7 months ago
Popups that come from the web. For instance, go to https://duckduckgo.com/ and try to install their addon with xpinstall.enabled set to false.

Comment 13

7 months ago
I'm confused.  You said the patch here check for locked since if it is unlocked you can just disable it from the popup.  But the scenarios affected by this patch do not create popups.
(Assignee)

Comment 14

7 months ago
> I'm confused.  You said the patch here check for locked since if it is unlocked you can just disable it from the popup.  But the scenarios affected by this patch do not create popups.

Sorry for the confusion. What I was saying is that historically we've used the locking of the xpinstall.enabled pref to false to mean "disabled by administrator" because just setting it to false does nothing useful so no one would ever do that. That's why I chose to use the locking as the criteria here. I'm more than happy to do either. I'm working on a new patch now that covers your comments.

My example was just to show how useless xpinstall.enabled set to false was and to point out that no one does that :)

Comment 15

7 months ago
I see and I agree that is useless.  But whether it is useful and whether it behaves consistently are two separate things.  Lets make it behave consistently even if it is useless :)
Comment hidden (mozreview-request)

Comment 17

7 months ago
mozreview-review
Comment on attachment 8956122 [details]
Bug 1269294 - Prevent add-on install from add-ons manager if xpinstall disabled and locked.

https://reviewboard.mozilla.org/r/225054/#review231448

::: toolkit/mozapps/extensions/content/extensions.js:336
(Diff revision 2)
> +function XPInstallDisabled() {
> +  return !Services.prefs.getBoolPref(PREF_XPI_ENABLED, true);
> +}

sorry for the churn but now that we've taken out the locked check, this can just be a lazy preference getter
Comment hidden (mozreview-request)

Comment 19

7 months ago
Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/475eae4a6baf
Prevent add-on install from add-ons manager if xpinstall disabled and locked. r=aswan

Comment 20

7 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/475eae4a6baf
Status: NEW → RESOLVED
Last Resolved: 7 months ago
status-firefox60: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
Assignee: nobody → mozilla
status-firefox49: affected → ---

Comment 21

6 months ago
Created attachment 8958375 [details]
Bug1269294.gif

I can reproduce the issue on Firefox 58.0.2 (20180206200532) under Win 7 64-bit.

With drag & drop or “Install Add-on From File” option and the preference xpinstall.enabled set to false, the extension can be installed in Add-ons Manager.

On Firefox 60.0a1 (20180312220041) and Firefox 60.b3 (20180312152746) under Win 7 64-bit and Mac OS X 10.13.2 the two scenarios mentioned above do not work when xpinstall.enabled is set to false.

Scenarios:
 * Put a XPI file into %AppData%/Mozilla/Firefox/Profiles/xxxx.default/extensions/
 * Put a XPI file into %appdata%/Mozilla/Extensions/
 * For instance, go to https://duckduckgo.com/ and try to install their addon with xpinstall.enabled set to false.
 * Install the extension from about:debugging.

For the scenarios mentioned above, the extension can be installed with xpinstall.enabled set to false on all the Firefox builds.

Is this expected or these scenarios will be covered by https://bugzilla.mozilla.org/show_bug.cgi?id=1429131 ?
Flags: needinfo?(mozilla)
(Assignee)

Comment 22

6 months ago
(In reply to CosminB from comment #21)
> Created attachment 8958375 [details]
> Bug1269294.gif
> 
> I can reproduce the issue on Firefox 58.0.2 (20180206200532) under Win 7
> 64-bit.
> 
> With drag & drop or “Install Add-on From File” option and the preference
> xpinstall.enabled set to false, the extension can be installed in Add-ons
> Manager.
> 
> On Firefox 60.0a1 (20180312220041) and Firefox 60.b3 (20180312152746) under
> Win 7 64-bit and Mac OS X 10.13.2 the two scenarios mentioned above do not
> work when xpinstall.enabled is set to false.
> 
> Scenarios:
>  * Put a XPI file into
> %AppData%/Mozilla/Firefox/Profiles/xxxx.default/extensions/
>  * Put a XPI file into %appdata%/Mozilla/Extensions/

These two scenarios would be addressed by the administrator not allowing local file access. We are not addressing them in product at this time.

>  * For instance, go to https://duckduckgo.com/ and try to install their
> addon with xpinstall.enabled set to false.

Setting to false is actually not enough to prevent installs, it has to be locked. The policy manager does this.

>  * Install the extension from about:debugging.

This will be handled in https://bugzilla.mozilla.org/show_bug.cgi?id=1443242
> 
> For the scenarios mentioned above, the extension can be installed with
> xpinstall.enabled set to false on all the Firefox builds.
> 
> Is this expected or these scenarios will be covered by
> https://bugzilla.mozilla.org/show_bug.cgi?id=1429131 ?

That bug will handle locking the pref and blocking about:debugging which will handle some of these cases.
Flags: needinfo?(mozilla)

Comment 23

6 months ago
> I can reproduce the issue on Firefox 58.0.2 (20180206200532) under Win 7
> 64-bit.
> 
> With drag & drop or “Install Add-on From File” option and the preference
> xpinstall.enabled set to false, the extension can be installed in Add-ons
> Manager.
> 
> On Firefox 60.0a1 (20180312220041) and Firefox 60.b3 (20180312152746) under
> Win 7 64-bit and Mac OS X 10.13.2 the two scenarios mentioned above do not
> work when xpinstall.enabled is set to false.

Based on comment 21 and comment 22, this issue is verified as fixed.

Thanks Mike!
Status: RESOLVED → VERIFIED
status-firefox60: fixed → verified
status-firefox61: --- → verified
You need to log in before you can comment on or make changes to this bug.