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

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[YUKI "Piro" Hiroshi]

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.

Comment 1

[Andy McKay]

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.

Comment 2

[Andrew Swan [:aswan]]

https://bugzilla.mozilla.org/show_bug.cgi?id=1269292#c4 applies pretty much verbatim here.

Comment 3

[YUKI "Piro" Hiroshi]

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.

Comment 5

[NtH]

(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 6

[Mike Kaply [:mkaply]]

Attachment: Bug 1269294 - Prevent add-on install from add-ons manager if xpinstall disabled and locked.

Review commit: https://reviewboard.mozilla.org/r/225054/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/225054/

Comment 7

[Mike Kaply [:mkaply]]

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.

Comment 8

[Andrew Swan [:aswan]]

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()`.

Comment 9

[Andrew Swan [:aswan]]

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?

Comment 10

[Mike Kaply [:mkaply]]

(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

[Andrew Swan [:aswan]]

(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

Comment 12

[Mike Kaply [:mkaply]]

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

[Andrew Swan [:aswan]]

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.

Comment 14

[Mike Kaply [:mkaply]]

> 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

[Andrew Swan [:aswan]]

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 16

[Mike Kaply [:mkaply]]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/225054/diff/1-2/

Comment 17

[Andrew Swan [:aswan]]

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 18

[Mike Kaply [:mkaply]]

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

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/225054/diff/2-3/

Comment 19

[Pulsebot]

Pushed by [e-mail]:
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

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/475eae4a6baf

Comment 21

[CosminB]

Attachment: 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 ?

Comment 22

[Mike Kaply [:mkaply]]

(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.

Comment 23

[CosminB]

> 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!