1525357 - If the xpinstall policy is set to true, users can still drag drop extensions into their profile and then enable them

Status: VERIFIED FIXED

(Firefox :: Enterprise Policies, defect, P1)

Description

[Mike Kaply [:mkaply]]

Users can work around xpinstall being disabled by dragging and dropping XPIs into their profile directory and then they can be enabled.

We should prevent this.

Comment 1

[Mike Kaply [:mkaply]]

Attachment: Bug 1525357 - Don't allow third party installs if xpinstall disabled by policy.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/607f7e4918e9
Don't allow third party installs if xpinstall disabled by policy. r=kmag

Comment 3

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/607f7e4918e9

Comment 4

[Mike Kaply [:mkaply]]

Comment on attachment 9041546 [details]
Bug 1525357 - Don't allow third party installs if xpinstall disabled by policy.

Beta/Release Uplift Approval Request

Feature/Bug causing the regression

None

User impact if declined

Users are able to install add-ons even though admin disabled.

Is this code covered by automated tests?

No

Has the fix been verified in Nightly?

No

Needs manual test from QE?

Yes

If yes, steps to reproduce

Disable addons via policy.
Put an addon in the extensions directory.
Verify it has not been loaded

List of other uplifts needed

None

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

Policy only.

String changes made/needed

ESR Uplift Approval Request

If this is not a sec:{high,crit} bug, please state case for ESR consideration

Policy change to prevent case where users can work around admins preventing installs

User impact if declined

Users are able to install add-ons even though admin disabled.

Fix Landed on Version

67 (requested for 66)

Risk to taking this patch

Low

Why is the change risky/not risky? (and alternatives if risky)

if statement on existing policy.

String or UUID changes made by this patch

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Emil can you verify this by Monday? Thanks!

Comment 6

[Cristian Baica [:cbaica], Release Desktop QA]

Coming with a confirmation on behalf of Emil. The issue is verified fixed in Fx67.0a1 buildID: 20190222081112 on macOS 10.14, Ubuntu 16.04 x64 and Windows 10 x64. Here are the steps performed in confirming this fix:

1. Launch Firefox and create a new profile.
2. After Firefox is launched with the new profile, add the policy.
3. Restart Firefox and make sure the policy is applied in the about:policies section.
4. Copy/Paste the .xpi in the extensions folder of the profile.
   Actual Result: The .xpi is deleted after a Fx restart (and it does not show up in the addons sections).
5. Drag and drop the .xpi on the browser tab bar.
   Actual result: The user is informed that the addon cannot be installed.
6. Go to the AMO page and try installing an addon or a theme.
   Actual result: The user receives an error letting him know that the addon cannot be installed.

Please note that there is still a way to bypass the policy. See 1529251 for more details.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9041546 [details]
Bug 1525357 - Don't allow third party installs if xpinstall disabled by policy.

Verified in nightly; OK for uplift for beta 12.

Comment 8

[Razvan Maries]

Tried to uplift on beta but got an conflict on:
warning: conflicts while merging browser/components/enterprisepolicies/Policies.jsm! (edit, then use 'hg resolve --mark')
abort: unresolved conflicts, can't continue

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/67710331eb1f

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9041546 [details]
Bug 1525357 - Don't allow third party installs if xpinstall disabled by policy.

Fixes an edge case allowing addons to be installed even when disabled via policy. Approved for 60.6esr.

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr60/rev/f7f8499771e2

Comment 12

[Cristian Baica [:cbaica], Release Desktop QA]

I have tested the uplift using Fx 60.5.3 ESR (buildID: 20190304105950) and Fx 66.0b12 on macOS 10.14, Ubuntu 16.04 and Windows 10 x64. The policy is correctly applied and addons cannot be installed from the AMO page, by dragging and dropping the .xpi in Firefox or by copying the .xpi in the extensions folder of the profile. The about:debugging page is also blocked.

What I have noticed on the ESR build (Fx 60.5.3 ESR - buildID: 20190304105950), that after adding the policy on a fresh profile, accessing the about:addons page results in an infinite loading animation. I can confirm this is occurring on all 3 tested OS.

@Mike Would you like a separate ticket submitted for that or will you add a patch for that on this ticket?

Comment 13

[Ryan VanderMeulen [:RyanVM]]

File a new bug, please.

Comment 14

[Cristian Baica [:cbaica], Release Desktop QA]

I have submitted bug 1532674 to track the fix on the ESR build.

Comment 15

[Cristian Baica [:cbaica], Release Desktop QA]

Changing ESR flag to verified as work has been completed on bug 1532674.