Closed Bug 1455601 Opened 6 years ago Closed 6 years ago

Sandbox AutoConfig to its standard API in Firefox 62

Categories

(Core :: AutoConfig (Mission Control Desktop), enhancement)

Product:
Core
Component:
AutoConfig (Mission Control Desktop)
Version:
Other Branch
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla62
Tracking Flags:
Tracking Status
relnote-firefox --- 62+
firefox62 --- fixed

People

(Reporter: mkaply, Assigned: mkaply)

References

(Depends on 2 open bugs)

Details

(Keywords: feature)

Attachments

(1 file)

Bug 1455601 - Sandbox AutoConfig if sandbox_enabled pref is set.
59 bytes, text/x-review-board-request
kmag
: review+
Details 
Since the release of Firefox 57, we are seeing AutoConfig being used by bad actors. Because of that, we are going to be sandboxing AutoConfig to only its original API in Rapid Release version 62. We are not sandboxing on the ESR.

The APIs that will be available in AutoConfig on Rapid Release are:

pref(prefName, value) – sets the user value of a preference.

defaultPref(prefName, value) – sets the default value of a preference.

lockPref(prefName, value) – sets the default value of a preference and locks it. 

unlockPref(prefName) – unlocks a preference.

getPref(prefName) – retrieves the value of a preference

clearPref(prefName) – removes the user value of a preference, resetting it to its default value.

displayError(funcname, message) – displays an error in a specific format.

getenv(name) – allows you to query environment variables.

We will be removing getPrefBranch and the LDAP APIs (setLDAPVersion, getLDAPAttributes, and getLDAPValue).

If anyone requires AutoConfig outside of the standard API, we will be encouraging them to move to the ESR. We also hope for folks to tell us what kinds of things are missing so we can add them to the policy engine.
Mike: for release channel are we allowing access to some subset of preferences, or can anything be set?
(In reply to Mike Kaply [:mkaply] from comment #0)
> we are going to be sandboxing AutoConfig to only
> its original API in Rapid Release version 62. We are not sandboxing on the
> ESR.

I thought the plan was to remove this entirely for 62 and later, and to let it live on ESR for one last full cycle. Has the plan changed? If it has, why?
Flags: needinfo?(mozilla)
> I thought the plan was to remove this entirely for 62 and later, and to let it live on ESR for one last full cycle. Has the plan changed? If it has, why?

The patches from Kris were always about sandboxing the API, not removing it.

The policy engine does not provide for arbitrary setting/locking of preferences (and we have no plans to add it at this time). There are legitimate reasons for setting prefs that we don't include.

We have no plans to remove Autoconfig from ESR at this time.
Flags: needinfo?(mozilla)
> Mike: for release channel are we allowing access to some subset of preferences, or can anything be set?

Anything can be set (at least at this time). We have very little sense of the types of preferences people set, but we know they are all over the map. It might be interesting to get telemetry on the preferences that folks set (not the values).

Also, this will not affect things like search and new tab, since they aren't pref.

By the way, enabling sandboxed Autoconfig doesn't give anything that user.js doesn't give. user.js even allows locked preferences now.

https://bugzilla.mozilla.org/show_bug.cgi?format=default&id=440908

See an example user.js here:

https://github.com/ghacksuserjs/ghacks-user.js/blob/master/user.js

The advantage of Autoconfig is that it can do actual Javascript, so there can be logic behind pref choices.

Admins use this so they can do things based on whether a user is admin or not and using environment variables. We don't have that in policy yet.
Just to give a more real world example of this. In a standard CentOS build, they add a default preference file that contains all of these:

pref("app.update.auto",                     false);
pref("app.update.enabled",                  false);
pref("app.update.autoInstallEnabled",       false);
pref("browser.backspace_action",            2);
pref("browser.display.use_system_colors",   true);
pref("browser.download.folderList",         1);
pref("browser.link.open_external",          3);
pref("browser.shell.checkDefaultBrowser",   false);
pref("general.smoothScroll",                true);
pref("general.useragent.vendor",            "CentOS");
pref("general.useragent.vendorSub",         "FIREFOX_RPM_VR");
pref("intl.locale.matchOS",                 true);
pref("storage.nfs_filesystem",              false);
pref("dom.ipc.plugins.enabled.nswrapper*",  false);
pref("network.manage-offline-status",       true);
pref("toolkit.networkmanager.disable",      false);
pref("browser.startup.homepage",            "data:text/plain,browser.startup.homepage=file:///usr/share/doc/HTML/index.html");
pref("toolkit.storage.synchronous",         0);
pref("startup.homepage_override_url",       "http://www.centos.org");
pref("startup.homepage_welcome_url",        "http://www.centos.org");
pref("extensions.shownSelectionUI",         true);
/* Workaround for rhbz#1110291 */
pref("network.negotiate-auth.allow-insecure-ntlm-v1", true);
/* Workaround for mozbz#1063315 */
pref("security.use_mozillapkix_verification", false);
pref("geo.wifi.uri", "https://location.services.mozilla.com/v1/geolocate?key=%MOZILLA_API_KEY%");
pref("browser.tabs.remote.autostart",       false);
pref("javascript.options.baselinejit",      true);

There's been discussion of completely removing the ability to do drop in preferences in defaults/pref.

So the question is how would these get set? I can't imagine building policies for all of them...
It would be possible to keep AutoConfig unrestricted also on test channels (Nightly, aurora and unbranded)? Just like the idea behind allowing these channels to run legacy extensions and disable extension signing requirement. I think the reasoning is the same. Please. =)
> It would be possible to keep AutoConfig unrestricted also on test channels (Nightly, aurora and unbranded)

That's probably what will happen, but I'm not sure I see any advantage with that.
> That's probably what will happen,

Excellent news, thank you!

> I'm not sure I see any advantage with that.

With the understandable removal of legacy extensions support, unrestricted AutoConfig seems to be the only remaining way to customize Firefox beyond what is possible to do with WebExtensions API. I understand the security concerns with unrestricted AutoConfig on release channel (and future ESR, I guess), but test channels aimed to people who know the risks should never have this restriction.
> With the understandable removal of legacy extensions support, unrestricted AutoConfig seems to be the only remaining way to customize Firefox beyond what is possible to do with WebExtensions API.

What types of customizations are you talking about?
Everything you could do with legacy extensions but can't code with WebExt API. With unrestricted JS you can almost fork Firefox without recompiling it.

I use AutoConfig to improve my user experience. Some examples:

- Mouse/rocker gestures not limited to page content, working in toolbars (chrome process) too [similar non-WebExt: Mouse Gestures Redox];
- Autoselect the first urlbar popup entry when typing in urlbar (way better than default domain-only autocompleting) [similar non-WebExt: Enter Selects and Mozilla Labs: Prospector - Speak Words];
- Avoid unwanted history removal by accidentally pressing Delete when an item is selected in urlbar popup (I changed it to Shift + Delete);
- Status bar [similar non-WebExt: Status-4-Evar];
- When typing things like "node.js" or "layout.word_select.eat_space_to_next_word" in urlbar, even without prefixing them with search engine keyword Fx should load search results with default search engine, not try to load "http://www.node.js/" [similar non-WebExt: speedupcanonizeurl];
- Require master password to startup Firefox (not a big deal, just to drive away friends and family from my Fx profile) [similar non-WebExt: Master Password+];
- Highlight vertical position of Ctrl+F results on scrollbar [Chrome parity, similar non-WebExt: FindBar Tweak].

Etc. I have these and much more in my AutoConfig (it's like a Greasemonkey with userscripts that work as legacy extensions - the name of this 'concept' is userChromeJS).

Every Fx update I need to fix things in my code, no problem. I just want that forever there is a way to run unrestricted customized JS code on Fx startup. So if AutoConfig will remain unrestricted on Developer Edition I'm fine with that.
Kris:

I'd like to do the LDAP change separately. Trying to get this part done so I can get softvision testing
Comment on attachment 8980031 [details]
Bug 1455601 - Sandbox AutoConfig if sandbox_enabled pref is set.

https://reviewboard.mozilla.org/r/246200/#review252296

Thanks

::: extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp:101
(Diff revision 2)
>                                     const char *filename, bool bGlobalContext,
> +                                   bool bCallbacks, bool skipFirstLine,

Ugh. Can we get rid of the Hungarian typing while you're here? Below, too...

::: extensions/pref/autoconfig/src/nsReadConfig.cpp:139
(Diff revision 2)
> +    bool sandboxEnabled = false;
> +    rv = defaultPrefBranch->GetBoolPref("general.config.sandbox_enabled",
> +                                        &sandboxEnabled);

We should probably force this to true in release builds...

::: extensions/pref/autoconfig/src/nsReadConfig.cpp:305
(Diff revision 2)
>              for (uint32_t i = 0; i < amt; i++)
>                  buf[i] -= obscureValue;
>          }
>          rv = EvaluateAdminConfigScript(buf, amt, aFileName,
>                                         false, true,
> -                                       isEncoded ? true:false);
> +                                       isEncoded ? true : false,

Please just get rid of the ternary rather than fixing the spacing.
Attachment #8980031 - Flags: review?(kmaglione+bmo) → review+
Status: NEW → ASSIGNED
Pushed by mozilla@kaply.com:
https://hg.mozilla.org/integration/autoland/rev/bcae764555a8
Sandbox AutoConfig if sandbox_enabled pref is set. r=kmag
https://hg.mozilla.org/mozilla-central/rev/bcae764555a8
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
status-firefox62: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
Blocks: 1467685
Depends on: 1468702
Depends on: 1468734
Depends on: 1468941
Depends on: 1468963
I think we should have a documentation about "general.config.sandbox" somewhere. Otherwise admins won't notice until Firefox 62 is released.
Keywords: dev-doc-needed
(In reply to Masatoshi Kimura [:emk] from comment #21)
> I think we should have a documentation about "general.config.sandbox"
> somewhere. Otherwise admins won't notice until Firefox 62 is released.

Policy Engine/AutioConfig stuff is on SUMO, right? https://support.mozilla.org/en-US/products/firefox-enterprise

In which case, this is not a dev docs issue. I've need'info'ed Joni here, to see if she knows who to pass this on to (thanks Joni!)
Flags: needinfo?(jsavage)
Keywords: dev-doc-needed
This actually belongs in the beta release notes.



Release Note Request (optional, but appreciated)
[Why is this notable]: This is a major change for enterprise
[Affects Firefox for Android]: No
[Suggested wording]:

The release version of Firefox 62 will be sandboxing AutoConfig to the documented API. You can test this in Firefox beta by setting the preference general.config.sandbox_enabled to true. If you need to continue use more complex AutoConfig scripts, you will need to use the ESR.

[Links (documentation, blog post, etc)]:

Should link to this bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1455601
relnote-firefox: --- → ?
Flags: needinfo?(jsavage)
Added in 62 beta notes, with links to ESR download and support pages.
relnote-firefox: ? → 62+
Depends on: 1479857
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: