1429131 - Policy: Don't allow addons to be installed

Status: VERIFIED FIXED

(Firefox :: Enterprise Policies, defect, P1)

Description

[:Felipe Gomes (needinfo for replies!)]

Policy: Don't allow addons to be installed

This is controlled by the xpinstall.enabled pref

Comment 1

[:Felipe Gomes (needinfo for replies!)]

So it's not as simple as just that pref. Bug 1269294 has more details.

Comment 2

[:Felipe Gomes (needinfo for replies!)]

<andym> https://bugzilla.mozilla.org/show_bug.cgi?id=1359837
<+firebot> Bug 1359837 — FIXED, [e-mail] — If xpinstall.enabled is false and locked, pages should not be able to use mozAddonManager
<aswan> andym: https://bugzilla.mozilla.org/show_bug.cgi?id=1269294#c3
<aswan> i think "Install from File..." in about:addons also works if xpinstall.enabled is false
<andym> probably about:debugging too

Comment 3

[:Felipe Gomes (needinfo for replies!)]

<aswan> felipe: maybe an easier to implement design then would be a policy that enumerates the allowed addons instead of trying to catch all the places where new ones can be installed
<aswan> enabledScopes is about where you can sideload extensions
<felipe> ah ok
<aswan> that might be clunky, you could still go through the motions of installing an addon but we would refuse to enable it
<aswan> actually most? interactive installation code paths fail if the addon can't be immediately enabled

Comment 4

[Mike Kaply [:mkaply]]

I think we should fix the pref cases from bug 1269294. IF xpinstall.enabled is false, it should block the right code paths.

Comment 5

[YUKI "Piro" Hiroshi]

When this policy is activated, all addons installed under the profile folder should be uninstalled or deactivated. There are some scenarios which require this behavior.

Scenario 1:

 1. Firefox is deployed with minimum policies.
 2. A user installs addons. Those packages are placed under the profile folder.
 3. System administrator decides to disallow to install addons by users, and updates policies.json.
 4. Addons installed before the policy is applied are still available on the user's environment.

Scenario 2:

 1. Firefox is deployed with minimum policies.
 2. A user installs an addon "X" version 1.0. Its package is placed under the profile folder.
 3. System administrator decides to deploy the addon "X" version 2.0, thus updates policies.json
    and deploy the XPI file to client PCs under the application folder (C:\Program Files\Mozilla Firefox).
 4. "X version 1.0" is still loaded in the user's environment, because Firefox always loads
    addon files under the profile folder prior to the one under the application folder.

Comment 6

[Andrew Swan [:aswan]]

Mike, can you explain why you prefer this approach to the suggestion in comment 3?  I think a list of extensions would be easier to implement, and I suspect it would be closer fit for the actual policies that many administrators would like to implement (though you know much more about the latter question than any of the rest of us I think)

Comment 7

[Mike Kaply [:mkaply]]

> Mike, can you explain why you prefer this approach to the suggestion in comment 3?  I think a list of extensions would be easier to implement, and I suspect it would be closer fit for the actual policies that many administrators would like to implement (though you know much more about the latter question than any of the rest of us I think)

Blocking xpinstalls is quite easy and the preferences already exist (and have been used by admins for quite a while). My experience is that administrators preinstall the add-ons they want and simply turn off installing new add-ons.

I think longer term we could look at the blocklist idea, but I think it will be problematic with the way AMO does add-on IDs now. When you upload a new WebExtension, an ID is generated. How would you even know that add-on ID to whitelist it?

Comment 8

[Andrew Swan [:aswan]]

(In reply to Mike Kaply [:mkaply] from comment #7)
> Blocking xpinstalls is quite easy and the preferences already exist (and
> have been used by admins for quite a while). My experience is that
> administrators preinstall the add-ons they want and simply turn off
> installing new add-ons.

Okay.  Blocking installs is easy in theory.  As you noted in the linked bug though, there are some cases that aren't covered.  Even with that bug fixed, we'll have other cases that are still not covered.

> I think longer term we could look at the blocklist idea, but I think it will
> be problematic with the way AMO does add-on IDs now. When you upload a new
> WebExtension, an ID is generated. How would you even know that add-on ID to
> whitelist it?

I don't understand the problem here.  You can choose the ID if you like or if you don't choose one, AMO assigns one for you.  If you need to know the ID before submitting you can just choose it before submitting.  But I don't understand the scenario where you would need to know it before submitting.

Comment 9

[Mike Kaply [:mkaply]]

> Okay.  Blocking installs is easy in theory.  As you noted in the linked bug though, there are some cases that aren't covered.  Even with that bug fixed, we'll have other cases that are still not covered.

Can you give some examples?

> But I don't understand the scenario where you would need to know it before submitting.

If I wanted to allow a third party add-on from AMO, how do I find out that add-ons ID? In the old days, I could unpack and look at the install.rdf. In the new world, there's no guarantee of an ID...

Comment 10

[Andrew Swan [:aswan]]

(In reply to Mike Kaply [:mkaply] from comment #9)
> > Okay.  Blocking installs is easy in theory.  As you noted in the linked bug though, there are some cases that aren't covered.  Even with that bug fixed, we'll have other cases that are still not covered.
> 
> Can you give some examples?

None of the sideloading methods are affected by that preference.  Neither is about:debugging.

> > But I don't understand the scenario where you would need to know it before submitting.
> 
> If I wanted to allow a third party add-on from AMO, how do I find out that
> add-ons ID? In the old days, I could unpack and look at the install.rdf. In
> the new world, there's no guarantee of an ID...

Well every extension has an ID.  I'm not sure if it is displayed in AMO but you can get it via the API or you can see it for an installed extension in about:debugging or about:support

Comment 11

[Mike Kaply [:mkaply]]

> None of the sideloading methods are affected by that preference.  Neither is about:debugging.

Sideloading would be handled by an admin locking down installs on the maching.

Forgot about about:debugging. We should add a policy for that.

> Well every extension has an ID.  I'm not sure if it is displayed in AMO but you can get it via the API or you can see it for an installed extension in about:debugging or about:support

Good point. We'll want to document that when we built this policy.

Comment 12

[Mike Kaply [:mkaply]]

Attachment: Bug 1429131 - Add policy to lock xpinstall.enabled.

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

Comment 13

[Mike Kaply [:mkaply]]

FYI, I tested that this kicks in properly if you drag and drop a XPI on to the Firefox binary and it is blocked.

Comment 14

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8964636 [details]
Bug 1429131 - Add policy to lock xpinstall.enabled.

https://reviewboard.mozilla.org/r/233336/#review238940

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1661c8c1159a
Add policy to lock xpinstall.enabled. r=felipe

Comment 16

[:Felipe Gomes (needinfo for replies!)]

[Tracking Requested - why for this release]:
Enterprise Policies

Comment 17

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/1661c8c1159a

Comment 18

[Abe - QA (:Abe_LV)]

We tested this on the latest nightly with JSON policy format and it is verified as fixed.
With this policy, add-on installation can be disabled.

We will retest this with adm policy format when ready.

Test cases and runs are here- https://testrail.stage.mozaws.net/index.php?/plans/view/8760

Comment 19

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 8964636 [details]
Bug 1429131 - Add policy to lock xpinstall.enabled.

Approval Request Comment
[Feature/Bug causing the regression]: Enterprise Policies
[User impact if declined]: Policy to block addon installations by the user
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: -
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: simple pref flip
[String changes made/needed]: none

Comment 20

[:Felipe Gomes (needinfo for replies!)]

(I took the liberty to uplift this before the approval because it was in the middle of the patch queue and not including it would require everything else to be rebased)

https://hg.mozilla.org/releases/mozilla-beta/rev/16c3c8337b63913baa0f3fe797d7975d8e23d9a9

Comment 21

[Abe - QA (:Abe_LV)]

We retested this on beta builds with ADM and JSON policy formats and it is verified as fixed.

Test cases and runs are here- https://testrail.stage.mozaws.net/index.php?/plans/view/8760