Enterprise Management

Security Zones configurable by Mission Control

Mission Control is a preferred way to centrally manage Firefox. It is preferred over AD GPO management for contingency needs in a Microsoft tech-filled environment. For example, should AD infrastructure go down, Mission Control will be able to continue to offer a secured environment for browser usage.

Security-related settings are typically locked by Mission Control.

Internal and external sites typically have different trust levels and are assigned different Security/Trust Zones within IE. Similar functionality within Firefox grants better feature parity for Firefox.

In IE, zones are enforced by Group Policies. Likewise, Firefox should be configurable with it's autoconfig manager of choice, Mission Control.

Experience

Mission Control is unable to set certain setting at startup. Security Zone related settings, i.e. capability.policy group falls into that category.

Current model requires the user to self-opt into security zones by modifying the user.js file.

This is not an Enterprise-friendly way of managing something as high-risk as security zones.

Wish

Can "capability.policy" settings be overwritten by Mission Control?

References

http://www.mozilla.org/projects/security/components/ConfigPolicy.html

Exclude some settings from being written to Prefs.js or User.js

Firefox has a set order for applying runtime settings from a collection of default preferences files, user-defined preferences and autoconfig set preferences.

On application launch, the application loads preferences in the following order: Load all default pref files (program files/mozilla/firefox/greprefs, program files/mozilla/firefox/defaults/prefs). None-platform-specific .js files are loaded first, in reverse alphabetical order. Then the platform-specific file is loaded. Optionally load the autoconfig file. Load user pref files, first prefs.js, then user.js . Preference conflicts are resolved in favor of the last entry; for example, user.js takes precedence over prefs.js .

(This is from: http://www.mozilla.org/catalog/end-user/customizing/briefprefs.html)

With Mcontrol, a fourth step is added: Make a call to MControl via lockPref(""autoadmin.global_config_url"",${MControl_Server_Url}); setting in firefox.cfg What does MControl have to be able to do? Recognize which browser is asking it for settings serve up the right settings for the right browser User Agent String.

The user agent string is the only reliable way of differentiating one browser from the next when sending data over the net.

For this reason, institutional and enterprise clients may have the need to customize the UA string from the ""vanilla"" versions of the product. This helps guarantee that only the ""safe and supported"" version of the product is running.

All other flavors will typically get back a restrictive set of settings that will prevent the end-user from going out to the external network, downloading potentially harmful things etc.

Experience

Chicken and the Egg problem Because user.js and prefs.js files get evaluated last, the user can accidentally overwrite UA string and thus incorrectly identify herself to MControl during startup sequence.

Why does this happen? Firefox syncs down the deltas between defaults, user defined, and autoconfig settings to prefs.js. Any inconsistency introduced to prefs.js or user.js will cause a misconfiguration that cannot be automatically or cleverly resolved. Why can't it be resolved? MControl has to guarantee that the user is running a browser that is ""secured"" and ""configured"". If the browser is sending an unrecognized UA string to MControl for validation, MControl has to take the pessimistic approach and place the offending browser into a ""safe"", restrictive mode.

Why can't mcontrol just set the right UA string? In the event that the user is indeed not using a supported version of the browser, enabling it with a certified UA string will only guarantee that the next time the user launches the browser, she will obtained all the ""good"" configurations of a supported browsers. This cannot be allowed.

Where's the challenge? Only one version of Firefox is supported within our environment. Typically, this is the latest-and-greatest version with the latest security-related fixes. The chicken-and-the-egg problem makes it difficult to ""push"" out updates to users without having to touch active profiles.

So, once 1.5.0.9 is replaced by 1.5.0.10 and so updated as the ""recognized"" browser in MControl, all users will still have 1.5.0.9 in their prefs.js file due to the sync down process...

Profile Sanitization Solution Standardize profile naming so it can be programatically determined and standardized. We've chosen, %USERNAME%_%MOZ_VERSION% as the profile name, sans the random strings mozilla typically prepends to profile names. Programatically migrate user profiles for every upgrade - i.e. move %username%_1.5.0.9 to %username%_1.5.0.10. Update profiles.ini and set %username%_1.5.0.10 as the default/active profile Clean up prefs.js and user.js to get rid of any strings that may cause a conflict, i.e. ua string settings, mcontrol urls, etc.

Wish

When running in ""enterprise"" mode preferences that can conflict with the autoconfig boot-up sequence should simply not be allowed to sync down to user.js or prefs.js.

These settings should be ignored if read in from the user's profile and should not be flushed to the user's profile.

Candidates for this list:

• general.config.filename
• general.useragent.extra.firefox
• general.useragent.override
• autoadmin.global_config_url
• extensions.whitelist.*
• browser.safebrowsing.provider.*
• network.protocol-handler.*
• capability.policy.*

Extension Management

Extensibility is arguably the most user-friendly capability a product can grant it's end-user.

For an enterprise, extensions can be a huge productivity boost richer integration with biz-critical processes dashboard and at-a-glance view of important information personalization of user experience The list goes on.

Extensions are software and are held to the same high standards of ""risk management"" as anything else entering an enterprise environment.

Perhaps because a web browser is a critical tool in a Knowledge Worker's tool-box, extensions are held to even stricter standards.

To this end, an enterprise must retain the same amount of granular control for add-ons as it likes to retain for general software.

This list includes: Who can install? From where can one install? Who can uninstall? What can one uninstall? Can we shut down all extensions at the same time? Can we ask the browser to only load a particular version of an extension? What is the best way/mechanism to manage extension lifecycle?

Experience

Although Firefox 2.0/3.0 does provide a Mozilla-managed blacklist of extensions as well a a mechanism for the browser to sync with this list, this is not a favorable option for an enterprise that does not wish to ""phone home"".

How best to managing the extension lifecycle is still an open issue.

What we are currently doing is: Force Firefox to use whitelist of acceptable download locations for extensions. xpinstall.whitelist.required is locked to true via mcontrol. xpiinstall.whitelist.add.103 and xpinstall.whitelist.add set to internal web server hosting approved extensions Prevent user from adding other sites to the whitelistAct as vendors and sit between mozilla and our user community. All extension go through an approval pipeline before making it to the internal download area. Disable external .xpi download via Proxy

Wish

Managing Extensions Ideally, we would control the extension via Mission Control i.e. browser.extensions.enable.all=[true|false] browser.extensions.enable.$name=$version browser.extensions.disable.all=[true|false] browser.extensions.disable.$name=$version This enables us the ability to enforce either whitelists or blacklists. A proper implementation of MControl (with a backend hook-up to a corporate directory) can serve different flavors of these settings based on Department or Business Unit affiliation. This approach permits administrators the block or allow as much or as little as is required with minimal interruption to the user. (i.e. compare with having to push extensions and extension updates with something like SMS)

Extension repository An internal addons.mozilla-like application is preferred, i.e. addons.teama.com. This web-application can be web-serviced to automatically pull extension updates from the parent site. Some implemented workflow can facilitate the approval/publishing process.

Internal extension developers can potentially manage the life-cycle of their extension through this application.

Compiling autoconfig boot-up settings into the executable

Mission Control's mission-critical responsibility is to guarantee that the browser is ""configured"" and ""secured"". The user must not be allowed to circumvent Mission Control.

Experience

On an unlocked desktop, the user has access to the ""firefox.cfg"" file as well as the user preference files that instruct firefox to read in this file when booting up in autoconfig mode. The user can circumvent autoconfiguration by modifying the items mentioned above.

At the moment, we hope that users of unlocked desktops are not savvy enough to realize this work-around. This is clearly not an optimal risk-management strategy.

Wish

Autoconfig-related parameters should be compiled into the executable itself.

Example of items to include in this: 1) UA String 2) Turn mission control on/off 3) Supported MControl modes of operation, i.e. Prod, QA, Test

Patch Management

Provide MSI/MST for Enterprise Firefox package

coming soon along with others...