Sort of. You can apply lock down settings with mozilla.cfg. This, however, will prevent all users from using locked down features though. Administrators can of course swap in/out the config file at will.
Here's the list of settings we deploy via lock down. It's a K-12 environment, so your needs will likely vary.
lockPref("xpinstall.enabled", false);
lockPref("extensions.enabledScopes", 0); // Or 4 or 8 for approved extensions
Components.utils.import("resource://gre/modules/FileUtils.jsm");
var profExtDir = FileUtils.getDir("ProfD", ["extensions"], false, false);
if ( profExtDir.exists() )
Tech_a_break; // here anything undefined would suffice
Double slashes (//) outside code denote comments.
lockPref() specifies a policy i.e. mandatory - users cannot modify, whereas
defaultPref() or pref() specifies a preference i.e. nonmandatory - users may modify the initially set value.
Setting xpinstall.enabled to false disables all installations through (running) Firefox, i.e. installations from websites, Tools > Add-ons > [Get Add-ons | Search bar | gear icon], File > Open File, and drag-n'-drop. Installer formats are .xpi and .jar.
Setting extensions.enabledScopes to 0 disables all (except user (profile) folder (Scope 1), and admin folder) offline/manual discovery (once at every Firefox startup) locations.
The (user) Scope 1 hybrid location (user profile 'extensions' folder) is the only store of the first installation method and is obsoleted by setting xpinstall.enabled to false, but is not scoped out (extensions.enabledScopes) as a discovered location (second installation method). The second code block above throws an error whenever this location appears, and Firefox exits.
To enable approved extensions via Firefox install_directory\browser\extensions, set extensions.enabledScopes to 4, & add lockPref("extensions.autoDisableScopes", 11);
Alternatively (in Windows), to enable approved extensions via Windows registry HKLM, set extensions.enabledScopes to 8, and extensions.autoDisableScopes to 7. The equivalent in GNU/Linux is /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}
To enable both locations, use 12, and 3 respectively.
It's also possible to lockPref() or defaultPref() the settings of those extensions that integrate their configuration in about:config; usually the particular keys in about:config would include the extension name or part of the name or em:id.
Download and unzip FoxyProxy into a top-level subfolder in a network share (e.g. network share FxExts, and subfolder foxyproxy). Next, rename the foxyproxy subfolder with the value between the em:id tags in the unzipped install.rdf file - foxyproxy is renamed as [email protected].
Next, in a text file enter the path in the first line, i.e. \\server\FxExts\[email protected], and also rename the text file (including the .txt extension) with the em:id value - New Text Document.txt is renamed as [email protected].
These text files can be distributed to existing Firefox install_directory\browser\extensions, or included in the Firefox installer core\browser\extensions.
At every startup Firefox goes through the text files, and deletes (under admin accounts) any on error or if the share is unavailable at the time. To prevent this after testing, use group policy to [set Deny deletes permissions on the extensions folders, and/or offline cache the share (FxExts)].
To disable an extension, rename the target extension's install.rdf to, for example disabled.rdf.
To update an extension, delete the contents in its subfolder and unpack the new XPI. Usually the unique em:id would be the same.
If extensions.autoDisableScopes is set to 15, users would be able to search for, and activate preferred extensions via Tools (Alt + T) > Add-ons: Search bar. Alternatively, enable one location for auto activated extensions which would leave the other for user (manually) activated extensions.
Policy filtering (selectively apply settings in the lock file):
In Windows, Deny the Read Data permission on local-settings.js for the users/groups to be exempted. In GNU/Linux systems one option would be to set the base permissions of local-settings.js as 0600 (with root being the ug), add all users to a group (e.g. fxgrp) leaving out the to-be-exempt users, and then setfacl -m g:fxgrp:r local-settings.js
Please note that using OS environment variables is unsafe as it can be bypassed, unless extra measures outside of the lock (policy) file are implemented.
Misc.: The Browser Console's command bar can be disabled by a CSS rule in a style sheet e.g. .jsterm-input-container {display:none;} To centralize this style sheet via lock (policy) file:
var css = Components.classes["@mozilla.org/content/style-sheet-service;1"]
.getService(Components.interfaces.nsIStyleSheetService);
var ioSvc = Components.classes["@mozilla.org/network/io-service;1"]
.getService(Components.interfaces.nsIIOService)
.newURI("file://///server/share/Fx.css", null, null);
css.loadAndRegisterSheet(ioSvc, 1);
Fx.css (style sheet) is loaded in Firefox Safe Mode too, and can specify both chrome (Firefox UI), and content (internal pages, web pages) rules. For NFS, or SMB mounts, or local filesystem, use file:///
[userChrome and userContent].css have the highest precedence, so it would be good to check for the chrome folder too, e.g. var profChrmDir = FileUtils.getDir("UChrm", false, false); if( profExtDir.exists() || profChrmDir.exists() )
The other tools, and the GCLI can be disabled as is needed via the lock (policy) file - filter for devtools*enabled in about:config.
For the details about the nsInterfaces in Components.interfaces.* please see XPCOM interfaces.
PS: To reliably catch errors and conditions in the .cfg file of some Firefox editions, it may be necessary to put the whole lock (policy) contents inside a try block, e.g. try { var ...; lockPref(); } catch(e) { Components.utils.import("resource://gre/modules/Services.jsm"); Services.startup.quit(0x03); } Optionally also include Services.prompt.alert(null, "Firefox", "Failed to start. Please inform the IT dept."); in the catch(e) { } block.
Preventing users from installing addons is more difficult in later versions of Firefox. Firefox does not honor the xpinstall.enabled preference in some versions. (Edit: see comment below: they do honor this preference as of version 31)
For a detailed write-up on how to modify Firefox to prevent Add-on Manager from displaying and how to prevent users from installing add-ons, check out this article.
The instructions are not for the faint of heart, but they do work; I have 700 machines locked down in a K-8 environment using these directions.
For more information on locking down browser settings, check out this article.
Sort of. You can apply lock down settings with mozilla.cfg. This, however, will prevent all users from using locked down features though. Administrators can of course swap in/out the config file at will.
Here's the list of settings we deploy via lock down. It's a K-12 environment, so your needs will likely vary.
Also see the locked config settings on to the official Mozilla.org docs.
This is a variation, compiled from the helpful details @ MDN, MozillaZine, PCC-Services, Mike's Musings
To block/prevent extensions (include this in the lock (policy) file):
Double slashes (//) outside code denote comments.
lockPref()
specifies a policy i.e. mandatory - users cannot modify, whereasdefaultPref()
orpref()
specifies a preference i.e. nonmandatory - users may modify the initially set value.Setting
xpinstall.enabled
to false disables all installations through (running) Firefox, i.e. installations from websites, Tools > Add-ons > [Get Add-ons | Search bar | gear icon], File > Open File, and drag-n'-drop. Installer formats are .xpi and .jar.Setting
extensions.enabledScopes
to 0 disables all (except user (profile) folder (Scope 1), and admin folder) offline/manual discovery (once at every Firefox startup) locations.The (user) Scope 1 hybrid location (user profile 'extensions' folder) is the only store of the first installation method and is obsoleted by setting xpinstall.enabled to false, but is not scoped out (extensions.enabledScopes) as a discovered location (second installation method). The second code block above throws an error whenever this location appears, and Firefox exits.
about:config, about:config Entries, Config Descriptions extension, Installing extensions, Special locations
Approved extensions
To enable approved extensions via Firefox install_directory\browser\extensions, set
extensions.enabledScopes
to 4, & addlockPref("extensions.autoDisableScopes", 11);
Alternatively (in Windows), to enable approved extensions via Windows registry HKLM, set
extensions.enabledScopes
to 8, andextensions.autoDisableScopes
to 7. The equivalent in GNU/Linux is /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}To enable both locations, use 12, and 3 respectively.
It's also possible to
lockPref()
ordefaultPref()
the settings of those extensions that integrate their configuration in about:config; usually the particular keys in about:config would include the extension name or part of the name or em:id.Internal store, Centralized extensions (FoxyProxy as example):
Download and unzip FoxyProxy into a top-level subfolder in a network share (e.g. network share FxExts, and subfolder foxyproxy). Next, rename the foxyproxy subfolder with the value between the em:id tags in the unzipped install.rdf file - foxyproxy is renamed as [email protected].
Next, in a text file enter the path in the first line, i.e. \\server\FxExts\[email protected], and also rename the text file (including the .txt extension) with the em:id value - New Text Document.txt is renamed as [email protected].
These text files can be distributed to existing Firefox install_directory\browser\extensions, or included in the Firefox installer core\browser\extensions.
Alternatively or additionally via registry HKLM: Name [email protected], and Data \\server\FxExts\[email protected]
In either or both cases (Scopes 4 and 8):
To disable an extension, rename the target extension's install.rdf to, for example disabled.rdf.
To update an extension, delete the contents in its subfolder and unpack the new XPI. Usually the unique em:id would be the same.
If
extensions.autoDisableScopes
is set to 15, users would be able to search for, and activate preferred extensions via Tools (Alt + T) > Add-ons: Search bar. Alternatively, enable one location for auto activated extensions which would leave the other for user (manually) activated extensions.Policy filtering (selectively apply settings in the lock file):
In Windows, Deny the Read Data permission on local-settings.js for the users/groups to be exempted. In GNU/Linux systems one option would be to set the base permissions of local-settings.js as 0600 (with root being the ug), add all users to a group (e.g. fxgrp) leaving out the to-be-exempt users, and then
setfacl -m g:fxgrp:r local-settings.js
Please note that using OS environment variables is unsafe as it can be bypassed, unless extra measures outside of the lock (policy) file are implemented.
Misc.: The Browser Console's command bar can be disabled by a CSS rule in a style sheet e.g.
.jsterm-input-container {display:none;}
To centralize this style sheet via lock (policy) file:Fx.css (style sheet) is loaded in Firefox Safe Mode too, and can specify both chrome (Firefox UI), and content (internal pages, web pages) rules. For NFS, or SMB mounts, or local filesystem, use
file:///
[userChrome and userContent].css have the highest precedence, so it would be good to check for the chrome folder too, e.g.
var profChrmDir = FileUtils.getDir("UChrm", false, false); if( profExtDir.exists() || profChrmDir.exists() )
Chrome element names and IDs, Chrome URLs, Working with chrome URLs
The other tools, and the GCLI can be disabled as is needed via the lock (policy) file - filter for
devtools*enabled
in about:config.For the details about the nsInterfaces in Components.interfaces.* please see XPCOM interfaces.
PS: To reliably catch errors and conditions in the .cfg file of some Firefox editions, it may be necessary to put the whole lock (policy) contents inside a try block, e.g.
try { var ...; lockPref(); } catch(e) { Components.utils.import("resource://gre/modules/Services.jsm"); Services.startup.quit(0x03); }
Optionally also includeServices.prompt.alert(null, "Firefox", "Failed to start. Please inform the IT dept.");
in the catch(e) { } block.XPConnect, XPCOM interfaces, JSCM, omni.ja, JS reference, quick JS, JS
Preventing users from installing addons is more difficult in later versions of Firefox. Firefox does not honor the xpinstall.enabled preference in some versions. (Edit: see comment below: they do honor this preference as of version 31)
For a detailed write-up on how to modify Firefox to prevent Add-on Manager from displaying and how to prevent users from installing add-ons, check out this article.
The instructions are not for the faint of heart, but they do work; I have 700 machines locked down in a K-8 environment using these directions.
For more information on locking down browser settings, check out this article.