380871 - Cannot find a way to centralize and secure Extension Manager managed addon installation

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Sébastien Dehennault]

User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; (R1 1.5); .NET CLR 1.1.4322; InfoPath.1; MEGAUPLOAD 1.0; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

We are at present investigating the possibility of deploying Firefox as Internet browser in our organisation.

For such a deployment to be successful, we need to be able to control the software's behaviour in a number of aspects. More precisely, as for both practical and security reasons we have to be able to control the installed version of the software and its plugins and addons, any software update and / or installation has to managed internally and distributed centrally. It should not be possible for a user to bypass this process.

The best solution we could find to block a user from installing unauthorized addons is to modify the fileIsItemPackage(file) function in the nsExtensionManager.js script, by removing the xpi and jar extensions. This has the desired result, as the addon installation is not proposed, even if a xpi file exists in the extensions folder.

However, we have noticed that simply copying the directory containing an already installed addon from another computer into the extensions folder results in the addon being available in Firefox without any further action. Normally, a standard user will not be able to copy to C:\Program Files\Mozilla Firefox\extensions, but he does have access to %appdata%\Mozilla\Firefox\Profiles\d8mn5o2t.default\extensions, which has the same effect: 

What measures can you propose to block this, taking into account that Firefox's profile manager allows a user to create a new profile and thereby bypass any change in permissions that we could apply to the %appdata%\Mozilla\Firefox\Profiles\d8mn5o2t.default\extensions  folder?

I look forward to your reply, and thank you in advance for your kind cooperation.

Yours sincerely,

Sébastien Dehennault
European Parliament


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Daniel Veditz [:dveditz]]

This is a reasonable request so maybe this bug can turn into an enhancement bug (feature request), but Bugzilla is not a technical support channel and you probably need a solution much faster than any change could be made to the main product. You should probably contact the folks at mozilla-europe (cc'ing Tristan)

Note that there are also windows registry keys that can result in loading both plugins and extensions. Shouldn't be a problem on a locked-down installation, but we need to be able to turn these off too.
http://developer.mozilla.org/en/docs/Adding_Extensions_using_the_Windows_Registry

Comment 2

[Daniel Veditz [:dveditz]]

If you have locked down the installation directory you should be able to "lock" preferences using the CCK tool (custom configuration kit?). One pref you can turn off is xpinstall.enabled, that should be sufficient to prevent people from installing packages off the web without changing the extension manager code, although it won't prevent processing .xpi files that are manually copied into the right profile location.

Comment 3

[Sébastien Dehennault]

This is exazctly our problem "it won't prevent processing .xpi files that are manually copied into the right profile location."

We want a real solution to not allow this.

any idea ?

Comment 4

[Sébastien Dehennault]

Just 1 point, for us it's a bug, and it's major for our environment.

It's a bug because there is a feature in to turn off this automatique installation and this feature could be avoided by a standard user, this is not "normal".

It is major for us because we cannot deploy FireFox in our institution without this feature working.

But if necessary, we are open to a support solution.

Comment 5

[Mike Kaply [:mkaply]]

If the user has physical access to the hard drive (move/copy files, etc.), there's really not much you can prevent them from doing...

Comment 6

[Gervase Markham [:gerv]]

mkaply: that's not exactly true. We could, for example, have a preference to disable profile-specific plugins and extensions (and they could lock that pref in the normal manner). So we would not look for plugins or extensions in the directory they could write to.

Sébastien: is this the complete scope of your problem? Blocking end user extension and plugin installation into the profile? Or is there more?

Gerv

Comment 7

[Benjamin Smedberg]

gerv, mkaply is correct: if the user can write to their profile, they could install Firefox into their profile to bypass the restrictions entirely. IMO this is not a problem worth solving.

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to comment #4)
> Just 1 point, for us it's a bug, and it's major for our environment.

Please allow me to make a small point on Bugzilla customs: fields are filled in from the perspective of the product or the developer working on it. Severity "major" means "major loss of functionality" in Firefox itself. While this issue may prevent your organization's use of Firefox and be entirely legitimate in that context, it is not "major loss of functionality" to the vast majority of users (especially since that functionality never existed).

> It's a bug because there is a feature in to turn off this automatique
> installation and this feature could be avoided by a standard user, this is not
> "normal".

Our intention with the xpinstall.enabled pref was the ability for users to prevent websites (remote) from installing things, what users did to their own machines was in our estimation their business. From that perspective this issue represents an additional requirement and would require considerable additional code and re-design should we attempt it; it is not simply a "bug" (mistake).

[One could argue that the pref should prevent the unpacking of local .xpi files--and I will since I suspect bypassing the pref also bypasses the signature verification and that would annoy me--but it was absolutely never intended to prevent the discovery and use of chrome files found in the profile. And if you don't prevent that it's as easy to put a .xpi in the profile as to unzip it so that doesn't help your problem.

Comment 9

[Daniel Veditz [:dveditz]]

I've logged a related issue at bug 381525. That's not likely to be an issue for Sébastien since they've no doubt locked-down the registry.

Comment 10

[Sébastien Dehennault]

(In reply to comment #6)
> Sébastien: is this the complete scope of your problem? Blocking end user
> extension and plugin installation into the profile? Or is there more?
> Gerv

What we need is a way to block any installation or modifications of our configuration by a standard user (ie non-admin).
There is a lot of security concerns when allowing users to add extensions in a professionnal environment.

(In reply to comment #8)
I understand the point of view about the bug, I have post a mail for support at Mozilla but no reaction until now.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

This isn't a blocker for Firefox 3, as it's not on the PRD as part of the critical path.

Comment 12

[chris hofmann]

These items in http://wiki.mozilla.org/Firefox3/Product_Requirements_Document , although they still lack detailed specification, could provide the greater control over plugins and extensions that I think is being requested in this bug.  

P1 - SPI-003b - Countermeasures for Java/plugin/extension vulnerabilities (disable, warn, offer updates)

P2 - CON-002c - Identify ways to mitigate plugin crashes

P1 - ADD-003e  Unify add-ons management system and add plugin management system

They all look to be at risk for making Fx3.

Comment 13

[Mike Kaply [:mkaply]]

The only practical way I could see to do this is with an extension "whitelist" that dictated the only extensions allowed on the system.

In a true locked down environment, users wouldn't have access to the file system, so this problem wouldn't happen.

Comment 14

[Robert Strong (they/them - no direct email)]

Splitting this off into being about EM managed add-on installation. Plugin installation is an entirely different beast and would need to be handled separately.

Comment 15

[Sébastien Dehennault]

(In reply to comment #13)
> The only practical way I could see to do this is with an extension "whitelist"
> that dictated the only extensions allowed on the system.
> In a true locked down environment, users wouldn't have access to the file
> system, so this problem wouldn't happen.

Ok; but a user may always access to his profile and with firefox you can install plugin anywhere (you may create a profile in a place you have access right)

Comment 16

[Dave Townsend [:mossop]]

It reads to me like the solution here actually is bug 381525 or at least an extension of it. Maybe we would want a pref with something like the following values:

0 - Load no extensions
1 - Load extensions only from install dir
2 - Load extension only from install and profile dir
3 - Load extensions from everywhere.

This pref could be locked in the usual manner. Levels 0 and 1 would also disable extension installation during browsing and presumably update checking.

Obviously there are still ways that users could work around this, there always will be but it provides protection for the basic cases I think.

Comment 17

[Dave Townsend [:mossop]]

extensions.enabledScopes controls what install locations we will load extensions from so I'm calling this fixed by bug 555486

Comment 18

[Mike Kaply [:mkaply]]

We need some docs then. The only reference to extensions.enabledScopes is here:

https://developer.mozilla.org/en/Addons/Add-on_Manager/AddonManager#Installation_scopes

And it doesn't even say what the various values of the pref can be (it has names, not values)

Comment 19

[Dave Townsend [:mossop]]

I guess this falls under dev-docs and not user-docs, but not totally sure.

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #18)
> We need some docs then. The only reference to extensions.enabledScopes is

To help someone to write those docs here are the available scopes:
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/AddonManager.jsm#1189

Dave, what is necessary to disallow the loading of installed extensions from each of the locations? I tried it with extensions.enabledScopes=0 but without success. Even specifying 1 or 5 didn't change anything.

Comment 21

[Dave Townsend [:mossop]]

Documented this at https://developer.mozilla.org/en/Installing_extensions#Disabling_install_locations

(In reply to comment #20)
> Dave, what is necessary to disallow the loading of installed extensions from
> each of the locations? I tried it with extensions.enabledScopes=0 but
> without success. Even specifying 1 or 5 didn't change anything.

Was this just bug 660898 or something else? If so please file a bug.