I'm not sure what URLBlacklist is. Do you mean this? http://urlblacklist.com/ That is not a Google product and is not part of Chrome.

It is not a security goal for Chrome to block access to its own features. For more information, please see the Chrome Security FAQ: https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-

Oh I see, perhaps you meant http://www.chromium.org/administrators/policy-list-3#URLBlacklist ?

I still don't think we're going to consider blocking Chrome's own UX a security goal, though.

you should also consider upgrading from 48.0.2564.116 - the latest Chrome Stable version is 51.0.2704.106

Our deployment plan is part of a migration and therefore all upgrades are disabled by policy. The browser will be updated on an as required/approved basis dependent on business and security reviews of later versions. 

Regards

Brian Parker

I have worked out why the policies were not applying - there are three issues :-
1. If you set * for URLBlacklist it overrides all - even entries in URLWhitelist are ignored.
2. The policies when set are case sensitive. That is, if you add chrome://Version is wll be ignored, but if you add chrome://version, it will be blocked.
3. To block settings, extensions, history and clearbrowserdata in the GUI part, requires putting an additional "chrome" in the URL path. So for example, to block access to settings, you need to blacklist :-
chrome://chrome/settings

The only way I found to achieve this aim is to explicitly include each browserURL in the URLBlacklist settings. There was no way to achieve this using wildcards.
Hope this is useful to companies who cannot use Chrome because its security settings are way too lapse for an Enterprise environment.

I don't think "won't fix" is acceptable for a security-based issue such as this !!

I set this bug to WontFix because it is not a Chrome security goal for Chrome to block access to its own functionality. (Again, please see the FAQ.)

However, it does sound like there are certain usability concerns, e.g. the case-sensitivity. CCing some Enterprise people who might want to weigh in on that.

Also, I would strongly urge you to upgrade your Chrome installations to the latest stable version and to continue to keep them up-do-date. That is by far the most secure deployment plan; there are multiple known bugs in older versions. (Just search this bug database for Fixed bugs of Type=Bug-Security.)

I'll keep the bug open so I can continue to engage with the customer.

It sounds like you'd like to be able to monitor activity of your users - this isn't a security issue per se, although I understand that you may use this monitoring to provide forensics if a machine has been compromised which may have *some* security benefit.

That said, I don't think that URLBlacklisting parts of Chrome will do what you want - users can always just use the Windows file manager to manually delete their profile. If you want to track browsing activity, you'll want to use force-installed extensions to capture browsing activity and store it some place (perhaps on a server) where it can't be tampered with. There are third party products/extensions that can help you with this.

Your description of how URLBlacklist works doesn't match my expectations - I'll do some testing and follow up here.

Hi, and thank you for the response. 

We lock down user machines so that the action you describe is not possible. It is, however possible in the default installation of google chrome, and this violated security policy. I therefore had to identify all the potential user loopholes (and there are a few) especially using browser URLs, and close them. I have now managed this but if Google chrome is to meet even average security requirements in the enterprise, I would suggest that you make this a lot easier. For example your policies to lock down history allow the user to delete this via a button. Your extensions policy does not block access to Developer mode, even though you have blocked this with a separate policy setting !!  Too many back doors for users which should at least have an option to lock down via policy settings. After all IE policy settings cover just about all possibilities. These are just suggestions and constructive comments which I hope you take in the spirit intended and do not represent the views of anyone but myself, and are based on personal experience. The fact of the matter is I did find a way to lock everything down, but it was more convoluted than one would have expected. 

Regards

Brian Parker

Thanks for the followup! How do you lock down machines so they can't delete things from the chrome profile directory? If Chrome (which is running as a user process) can access the user profile directory, then can't any other user process also access it?

As an aside, I just set the following two policies on my linux workstation:

  "URLBlacklist": ["chrome://*"],
  "URLWhitelist": ["chrome://policy"]

This blocks all chrome:// urls, except for chrome://policy, as expected, so I don't see the behavior you are describing in comment #5 - can you share a screenshot of your about://policy page?

Users have no access to c drive. I will try to get screenshot but might take some time as now working on unlocked version !

Regards

Brian Parker

Can you clarify what it means that users have no access to C drive? Clearly they can run apps that can access C drive, as otherwise Chrome wouldn't be able to write its history data to the history DB, etc. So what do you mean by "users have no access"? Can you clarify your setup a little further, as that will help me understand how you're locking things down and how we can assist from within Chrome?

As an aside, I've verified that URLBlacklist filtering is case sensitive as you suggest. This is OK for domain names (because chrome will downcase them), but it means that for the URL path you may need to do some regexp magic. In general, people use URLBlacklist to block entire schemes or domains, which is why this generally isn't a problem in practice.

As much as I can say is that users have no visibility of the C drive. Does that clarify ?

Regards

Brian Parker

Hi, thanks for confirming that I am not going mad ! As I have said, I was able to block all security related URLs whilst allowing access to UX related (eg print), by judicious use of the URLBlacklist settings but my tests showed that if you set this to *, it overrides anything which is in the Whitelisting exponent, this is why we have used only the blacklist option. 

Regards

Brian Parker

Understood that you saw this weird behavior where blacklist settings overrode whitelist settings - this is a serious bug, but I can't reproduce it (see my example policy from comment #10 that seemed to work correctly) so any information you can provide (like chrome://policy screenshot from a chrome instance that is showing this bug) would be helpful in allowing us to fix this.

Switching type to normal bug based on comment #16

I don't think I will be able to get screenshots as that project is done, but what I can tell you is that every URL showed "blocked by policy" and I checked that the registry settings were correctly in place. Also confirmed that both policy settings had applied correctly. I am sorry that I cannot be any more helpful. 

Regards

Brian Parker

OK, without further repro steps I can't investigate the URLBlacklist-overrides-URLWhitelist issue, so I'll close this issue pending further reports.

I've opened https://bugs.chromium.org/p/chromium/issues/detail?id=627749 to track the feature request to make URLBlacklist case-insensitive. Thanks for the report!