Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPO Wish: Search Engine policies also for RR #484

Open
MCHuijgen opened this issue Nov 1, 2019 · 25 comments
Open

GPO Wish: Search Engine policies also for RR #484

MCHuijgen opened this issue Nov 1, 2019 · 25 comments

Comments

@MCHuijgen
Copy link

The Search Engine policies are the only policies left that are limited to the ESR as far as I can see. All other policies that were limited to the ESR-versions were made available to the RR in 2018. Can these policies also be made available to the RR-versions?

@MCHuijgen
Copy link
Author

@mkaply : any chance of being implemented in the near future?

@mkaply
Copy link
Collaborator

mkaply commented Dec 16, 2019

Not setting the default engine. Do you just need to add an engine?

@MCHuijgen
Copy link
Author

MCHuijgen commented Dec 17, 2019

Mainly adding, yes, but also PreventInstalls and Default.

For Remove I found a workaround by blocking a specific built-in search engine via ExtensionSettings:
"SearchEngineName@search.mozilla.org": {
"installation_mode": "blocked"
},

But I think it would be neater to be able to do that with SearchEngines.

@volklord
Copy link
Contributor

volklord commented Jun 9, 2020

Any Reason for this policy being ESR only?

@mkaply
Copy link
Collaborator

mkaply commented Jun 9, 2020

It's to prevent bad actors using policies to do search hijacking. I'm looking at making most of it available except setting the default search engine.

@volklord
Copy link
Contributor

volklord commented Jun 9, 2020

Ok, thanks.
One more question if you allow: I don't want to hijack this issue, but will the change also affect policies.json or GPO only?

@mkaply
Copy link
Collaborator

mkaply commented Jun 9, 2020

One more question if you allow: I don't want to hijack this issue, but will the change also affect policies.json or GPO only?

Anything I do will be GPO and policies.json.

Chrome gets around this by only allowing certain policies if you are connected to an Active Directory. I felt like this was limiting (and kind of unfair) which is why we went the ESR only route.

In the wild, we know that Antivirus are using policies to allow the OS certificate store, so we know apps are using these for things other than enterprise management.

@MCHuijgen
Copy link
Author

Thanks for looking at making most of it available! I really appreciate that.

I understand you want to prevent default search engine hijacking, fair enough. But what about home page hijacking? Malicious actors can do that since long time with a policy, I wonder if that isn't just as bad as hijacking the default search engine. And since setting the home page isn't limited to ESR, why keep the default search engine limited to the ESR?

I don't mean to be disrespectful here, and maybe I'm seeing things wrong, but it doesn't seem quite logical to me.

Enabling this for RR would be really great for my organization (9000+ employees), and I guess other enterprise environments. We are using RR because we want to be able to quickly use new features, the ESR is too slow for us. And the lack of this particular policy is the only discomfort using the RR.

@mkaply
Copy link
Collaborator

mkaply commented Jun 10, 2020

I've restarted the conversation around this internally. Hopefully we can come up with a good solution.

@nick-n-dev
Copy link

Sorry for jumping on this thread, however i was just myself looking at why my policy for this wasn't being applied.
I'm not sure i understand the reasoning behind this at all...

i mean, if "bad actors" have acces to hijack your GPO's, then you have a LOT more to worry about than your browser homepage/search engines...just saying.

And besides...a LOT of people hate the fact that google is the default, probably one of the first things that gets deleted :)

Even adding them as Extensions>Uninstall entries (ie: @search.mozilla.org etc) doesn't work, like they're completely ignored.

@mkaply
Copy link
Collaborator

mkaply commented Oct 13, 2020

Unfortunately it's not my decision.

Even adding them as Extensions>Uninstall entries (ie: @search.mozilla.org etc) doesn't work, like they're completely ignored.

Other people have said this works (at least for removing things.

@eMPai-git
Copy link

eMPai-git commented Apr 6, 2021

Even adding them as Extensions>Uninstall entries (ie: @search.mozilla.org etc) doesn't work, like they're completely ignored.

Did you try both blocking via ExtensionSettings and removing via SearchEngines | Remove?

It only worked for me to add both in policies.json. Maybe it's the same for GPO.

{
  "policies": {
    "ExtensionSettings": {
      "google@search.mozilla.org": {
        "installation_mode": "blocked"
      }
    },
    "SearchEngines": {
      "Remove": [
        "Google"
      ]
    }
  }
}

@MCHuijgen
Copy link
Author

MCHuijgen commented Apr 6, 2021

@mkaply : Any good news since June last year?

I've restarted the conversation around this internally. Hopefully we can come up with a good solution.

I mean, I don't have an actual problem now: I'm removing (and adding) a search engine by setting Installation_mode to blocked/force_installed in ExtensionSettings (which applies to both RR and ESR), and can do the same thing with SearchEngines, but only with ESR? But what is the reasoning behind this? Why not also SearchEngines with RR? Or leave it out of SearchEngines and rely only on ExtensionSettings for adding/removing search engines? It is confusing for administrators like me and prone to error.

@mkaply
Copy link
Collaborator

mkaply commented Apr 21, 2021

@MCHuijgen It's because of a fear of search hijackers using policies.

We're investigating workarounds.

@MCHuijgen
Copy link
Author

@mkaply As mentioned before (June 10 2020), for changing policies in Windows one needs to have admin permissions (for writing to HKCU\Software\Policies). And if a piece of malware has admin permissions, a lot worse actions than just hijacking a search engine could be performed to harm Firefox. Search engine hijacking is the least thing to worry about then. So with all due respect I think this fear is unfounded.

@mkaply
Copy link
Collaborator

mkaply commented Apr 21, 2021

So with all due respect I think this fear is unfounded.

Yeah, we're getting there as well. What we're looking at is a ways to tell users their search is taken over my some other mechanism (policy or extension) as well as using telemetry to scope the problem.

We're moving closer to a solution.

@pawlakm
Copy link

pawlakm commented Feb 22, 2022

Hello,

Can we get an update on this feature request please ?

Have you explored the possibility to detect if firefox is installed as root and if policy file is owned by root, if yes allow the change, otherwise forbid it ? (similar checks can be done for Windows I guess)

If the blocking point is the ability to add new searchengines, please at least allow us to remove preinstaled ones and set one of the preinstalled ones as default through policies.

This feature is not only required for enterprises. I use ansible to generates policies + autoconfig.js/firefox.cfg to deploy a default firefox configuration and behavior on 20+ physical hosts and VMs in a "home" context. This allows me to keep all devices and configurations up to date with no hassle and create VMs quickly depending on my family's needs. The only limitation I have is the fact that I cannot set the default search engine to the one I need.

With all due respect, I don't understand the risk argument mentionned above as in any case In order to modify the autoconfig / policies I need to have sudo access anyway, which means that I can do much more harm than setting a "bad search engine". And why authorizing changing proxy settings through policies if you consider that there are security risks of harmful configurations ? I don't think you consider proxy attacks less harmful than search hijacking, am I wrong ?

If the issue is related to other aspects than security risks (risk of losing money from major search-engines for instance) please tell us.

Best regards,

@spirillen
Copy link

Mainly adding, yes, but also PreventInstalls and Default.

For Remove I found a workaround by blocking a specific built-in search engine via ExtensionSettings: "SearchEngineName@search.mozilla.org": { "installation_mode": "blocked" },

But I think it would be neater to be able to do that with SearchEngines.

Nice to see I'm not the only one who struggles to disable undesireble pre-installed "search" exstensions from dubious sources.

I have tried many ways to get rid of wikipedia, eBay, google, yahoo, youtube, amazon, bing and twitter, but nothing I can find is working; unfortunately not your suggestion as well.

Here are some of the settings I have been trying in my /etc/firefox/policies/policies.json

        "Extensions": {
            "Uninstall": [
                "google@search.mozilla.org",
                "startpage@search.mozilla.org",
                "yahoo@search.mozilla.org",
                "youtube@search.mozilla.org",
                "amazondotcom@search.mozilla.org",
                "bing@search.mozilla.org"
            ]
        },
"ExtensionSettings": {
"wikipedia@search.mozilla.org": {
                "installation_mode": "blocked",
                "blocked_install_message": "No thanks, we like privacy.",
                "install_sources": [
                    "https://addons.mozilla.org/*"
                ]
            },
            "ebay@search.mozilla.org": {
                "installation_mode": "blocked",
                "blocked_install_message": "No thanks, we like privacy.",
                "install_sources": [
                    "https://addons.mozilla.org/*"
                ],
                "allowed_types": [
                    "extension"
                ]
            },
            "google@search.mozilla.org": {
                "installation_mode": "blocked"
            },
            "startpage@search.mozilla.org": {
                "blocked_install_message": "No thanks, we like privacy.",
                "install_sources": [
                    "https://addons.mozilla.org/*"
                ],
                "installation_mode": "blocked",
                "allowed_types": [
                    "extension"
                ]
            },
            "yahoo@search.mozilla.org": {
                "blocked_install_message": "No thanks, we like privacy.",
                "install_sources": [
                    "https://addons.mozilla.org/*"
                ],
                "installation_mode": "blocked",
                "allowed_types": [
                    "extension"
                ]
            },
            "youtube@search.mozilla.org": {
                "blocked_install_message": "No thanks, we like privacy.",
                "install_sources": [
                    "https://addons.mozilla.org/*"
                ],
                "installation_mode": "blocked",
                "allowed_types": [
                    "extension"
                ]
            },
            "amazondotcom@search.mozilla.org": {
                "blocked_install_message": "No thanks, we like privacy.",
                "install_sources": [
                    "https://addons.mozilla.org/*"
                ],
                "installation_mode": "blocked",
                "allowed_types": [
                    "extension"
                ]
            },
            "bing@search.mozilla.org": {
                "blocked_install_message": "No thanks, we like privacy.",
                "install_sources": [
                    "https://addons.mozilla.org/*"
                ],
                "installation_mode": "blocked",
                "allowed_types": [
                    "extension"
                ]
            },
            "twitter@search.mozilla.org": {
                "blocked_install_message": "No thanks Elon Musk.",
                "install_sources": [
                    "https://addons.mozilla.org/*"
                ],
                "installation_mode": "blocked",
                "allowed_types": [
                    "extension"
                ]
            }
),

image
image
image

anyone who have better luck?? or suggestions for how to get rid of these creeps?

@MCHuijgen
Copy link
Author

MCHuijgen commented May 29, 2023

@spirillen This is the ExtensionSettings config that does the trick for my organisation to block the search engines. I don't use any other extension policies. I'm using it on Windows by the way.

 "ExtensionSettings": {
	"*": {
		"blocked_install_message": "Call the IT Service Desk to allow an extension.", 
		"installation_mode": "blocked"
	},
		"bolcom@search.mozilla.org": { 
		"installation_mode": "blocked" 
	},
		"ebay@search.mozilla.org": { 
		"installation_mode": "blocked" 
	},
		"amazon@search.mozilla.org": { 
		"installation_mode": "blocked" 
	},
		"marktplaats@search.mozilla.org": { 
		"installation_mode": "blocked" 
	}
}

@spirillen
Copy link

Thanks for your suggestion @MCHuijgen However I have tried that simplified approach with no luck.

and the test of "Extensions" is new as I was reading it I thought YES just what I have been looking for.

What I could come to think of is, if there are some kind of weight in the rules that isn't mentioned, which "Re-Activate" a disabled ruled with an included

PS Running linux amd64 (ubuntu 22.04) FF 102.11.0esr

@volklord
Copy link
Contributor

@spirillen I do this:

{
  "policies": {
    "SearchEngines": {
      "Remove": [
        "Google",
        "Amazon.com",
        "Amazon.de",
        "Bing",
        "Wikipedia (de)",
        "Wikipedia (en)",
        "eBay",
        "Twitter"
      ],
      "Default": "DuckDuckGo"
    },
    "ExtensionSettings": {
      "wikipedia@search.mozilla.org": {
        "installation_mode": "blocked"
      },
      "google@search.mozilla.org": {
        "installation_mode": "blocked"
      },
      "bing@search.mozilla.org": {
        "installation_mode": "blocked"
      },
      "amazondotcom@search.mozilla.org": {
        "installation_mode": "blocked"
      },
      "amazondotde@search.mozilla.org": {
        "installation_mode": "blocked"
      }
    }
  }
}

In "Default": "DuckDuckGo", assuming that duckduckgo or whatever you want to set as default, comes bundled with Firefox.
The thing is, am not sure, it "works", just because it was the only one left after removing/blocking the others.

@spirillen
Copy link

Hey @abisszett that works partly in Ubuntu FF-ESR and not at all on Debian 11, this is weird it is working for you guys and just not at all for me

Results:

image

image

image

@mkaply
Copy link
Collaborator

mkaply commented May 30, 2023

Are you ESR on Debian?

@volklord
Copy link
Contributor

volklord commented May 30, 2023

@spirillen If you go to about:policies and have a look at the errors, you will see something like Policy SearchEngines is only allowed on ESR. So it "works" only on ESR and if does on RR, that's a bonus, if not, well ya it's not supported.
My suggestion was meant as a workaround, not as a solution. The solution would be, when this is officially supported/documented and that's the purpose of this issue.
I tried different variants of:

{
  "policies": {
    "SearchEngines": {
      "Remove": [
        "SearchEngineName",
        "SearchEngineID",
      ],
    },
    "ExtensionSettings": {
      "SearchEngineName": {
        "installation_mode": "blocked"
      },
      "SearchEngineID": {
        "installation_mode": "blocked"
      }
    }
  }
}

Nothing worked as expected. So, we have to wait until someone is willing to fix this.

@spirillen
Copy link

spirillen commented May 31, 2023

Are you ESR on Debian?

Yes and on ubuntu as well

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants