Closed Bug 1429131 Opened 2 years ago Closed 2 years ago

Policy: Don't allow addons to be installed

Categories

(Firefox :: Enterprise Policies, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 61
Tracking Status
firefox60 + verified
firefox61 --- verified

People

(Reporter: Felipe, Assigned: mkaply)

References

Details

Attachments

(1 file)

Policy: Don't allow addons to be installed

This is controlled by the xpinstall.enabled pref
So it's not as simple as just that pref. Bug 1269294 has more details.
<andym> https://bugzilla.mozilla.org/show_bug.cgi?id=1359837
<+firebot> Bug 1359837 — FIXED, mozilla@kaply.com — 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
<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
I think we should fix the pref cases from bug 1269294. IF xpinstall.enabled is false, it should block the right code paths.
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.
Depends on: 1269294
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)
Flags: needinfo?(mozilla)
> 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?
Flags: needinfo?(mozilla)
(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.
> 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...
(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
> 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.
Assignee: nobody → mozilla
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 on attachment 8964636 [details]
Bug 1429131 - Add policy to lock xpinstall.enabled.

https://reviewboard.mozilla.org/r/233336/#review238940
Attachment #8964636 - Flags: review?(felipc) → review+
Pushed by felipc@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/1661c8c1159a
Add policy to lock xpinstall.enabled. r=felipe
[Tracking Requested - why for this release]:
Enterprise Policies
https://hg.mozilla.org/mozilla-central/rev/1661c8c1159a
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
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 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
Attachment #8964636 - Flags: approval-mozilla-beta?
(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
Attachment #8964636 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.