1514451 - Re-remove prefs for sandbox AutoConfig from release builds

Status: RESOLVED WONTFIX

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

Description

[Masatoshi Kimura [:emk]]

Since Talos dropped dependency on AutoConfig, we can now force sandboxing in release.

Comment 1

[Mike Kaply [:mkaply]]

This won't be done until Firefox 68.

Comment 3

[Mike Kaply [:mkaply]]

Attachment: Bug 1514451 - Force autoconfig sandbox on beta and release.

Comment 4

[dessant]

Forcing the AutoConfig sandbox on release builds prevents us from disabling extension signing on our own devices, and forces us to abandon the release version of Firefox, when the installation of private extensions is needed.

If I understand well, AutoConfig is used by editing files in the Firefox installation folder, and that effectively requires root access on the device.

It would be extremely important to allow us to continue customizing Firefox this way, as it does not present a security issue if the creation of config files is guarded by administrative access rights.

https://support.mozilla.org/en-US/kb/customizing-firefox-using-autoconfig

Comment 5

[Mike Kaply [:mkaply]]

We allow the installation of unsigned extensions in the ESR, nightly and dev edition, so those are the places to use private extensions.

The fact that you can disable signing in a release version of Firefox using autoconfig is one of the primary reasons we are forcing autoconfig to be sandboxed.

And it is a security issue. Users grant administrative rights all the time to adware/malware which does this. Requiring admin access to change files is not enough protection.

Comment 6

[dessant]

The threat model behind this decision is not clear. Can't malware just replace the Firefox executable? What is the security benefit of disallowing unsigned extensions without offering an option to disable it as an admin user?

Comment 7

[tobias]

We are too using Firefox and require unsandboxed AutoConfig. Our machines are running Fedora, who do not package ESR. (meaning, moving to ESR would require us to package Firefox ourselves or stop using the package manager -- both aren't feasable for us)

Since the threat model appears to be adware/malware: can this change please be limited to Windows only (or put another way: exclude Linux from this change)? MSWin is the main (if not only OS) that seems to have these problems.

Thanks!

Comment 8

[woky]

(In reply to Mike Kaply [:mkaply] from comment #5)

And it is a security issue. Users grant administrative rights all the time to adware/malware which does this. Requiring admin access to change files is not enough protection.

You know, malware with administrative rights can just replace Firefox binary with your "protections" disabled.

Comment 9

[tobias]

Just noticed that I forgot to mention our use case: Fixing CSP-merging using this autoconfig script. See also Bug 1421725 and Bug 1267027.

Comment 10

[Mike Kaply [:mkaply]]

Thunderbird will need this as well so LDAP works.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:mkaply, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 12

[Mike Kaply [:mkaply]]

dessant: what platform are you on?

We do not want to make it easy for people to disable signing. I understand you have this requirement. We have provided two ways to officially disable signing - use the ESR or use unbranded builds (https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded_Builds)

The fact that you can disable signing via autoconfig is one of the primary reasons we are doing this.

tobias: this won't apply for most Linux distros since they use a release channel of default.

Comment 13

[dessant]

I'm on Linux. It seems that leaving this possibility for customization open on Linux would have minimal risk, because the kind of adware this targets hasn't really been an issue on this platform. At the same time businesses that rely on patching Firefox would be able to continue using the release version of Firefox for testing on their servers.

Comment 14

[tobias]

(In reply to Mike Kaply [:mkaply] from comment #12)

most Linux distros since they use a release channel of default.

I'm not sure if that's true (please correct me if I'm wrong):

• Fedora's mozconfig specifies --enable-release and --update-channel=release
• Ubuntu uses the release channel too, here.
• Arch Linux' Pkgbuild specifies --enable-release and --enable-update-channel=release

Comment 15

[Mike Kaply [:mkaply]]

Interesting. Historically we've seen most Linux distros using "default" as their channel which has caused us problems in the past.

Comment 16

[Mike Kaply [:mkaply]]

WONTFIXing for now until we have more evidence this is an issue.