My guess as to why this happens is that policy-based blacklisting happens at the network layer in the browser process, but chrome://crash and chrome://kill are handled as the renderer is preparing to navigate in the renderer process (see https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?type=cs&l=812). This is before a network request is issued.

This isn't a security bug per se since I'm pretty sure it's working as intended, so I'm lifting the security restrictions.

What I'm not sure about is whether it's worth delaying the handling of chrome://crash and chrome://kill so that they can also be caught by the policy blacklist. +creis and +atwilson for thoughts.

Hmm, why would other URLs within IsRendererDebugURL not behave the same?  I'm curious why chrome://crash would still work if chrome://hang is blocked?

Enterprise folks, is there a way to test the blacklist on a local build?

creis: You should be able to put the policy in /etc/chromium/policies/managed/ for local testing.

I just did so and found that chrome://restart and chrome://hang both skip blocking. But chrome://badcastcrash/ seems to be blocked by the policy... maybe the forced bad cast crash doesn't work? In any case, MaybeHandleDebugURL() allows navigation to continue if a crash doesn't happen, so perhaps the non-blocked cases just aren't actually interrupting or taking over the control flow.

Igor, can you take a look at this when you're done with your current migration work? I agree that we should be able to block chrome:// URLs (and we definitely should have browser tests to catch this case).

Tested this issue on Skytap env with Win2K12 as server and Win7 as client with chrome #61.0.3163.67, blocked the following urls in the "URLBlackList" policy

chrome://crash,chrome://kill,chrome://restart,chrome://gpuhang,chrome://quit,chrome://gpuclean,chrome://version,chrome://settings,chrome://inducebrowsercrashforrealz

Observations:
==============
chrome://crash; chrome://kill; chrome://restart; chrome://quit; chrome://inducebrowsercrashforrealz following urls are not blocked.

Marking this as Untriaged as per C#6.

The flow goes through ChromeNetworkDelegate::OnBeforeURLRequest first, detects the the URL is in blacklist (all of them are identified correctly) but after that it ends up executing MaybeHandleDebugURL from render_frame_impl.cc.

So, all the pages are executed eventually the difference being it's noticeable only for some pages.

One way to fix this would be to not trigger MaybeHandleDebugURL for the error that is sent for URL blocked from URLBlacklist. But need to do it in a way that rendering code would not know about policy code.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7fced7b524d0ea7a165b0686e8d459880e1639f5

commit 7fced7b524d0ea7a165b0686e8d459880e1639f5
Author: clamy <clamy@chromium.org>
Date: Thu Nov 16 19:52:43 2017

Do not send renderer debug URLs to the network stack

Sending renderer debug URLs to the network stack will result in trying
to commit an error page, which is when the debug URL will actually be
handled. This causing issues when trying to block them.

This CL also ensures that debug URLs will never commit.

BUG= 776528 ,760732

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_site_isolation
Change-Id: Iaae35029e5fcd0b66c470468a8f90ca9736fff3e
Reviewed-on: https://chromium-review.googlesource.com/731083
Commit-Queue: Charlie Reis <creis@chromium.org>
Reviewed-by: Ned Nguyen <nednguyen@google.com>
Reviewed-by: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517157}
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/browser_url_handler_impl.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/frame_host/debug_urls.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/frame_host/debug_urls.h
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/frame_host/navigation_controller_impl.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/frame_host/navigation_handle_impl.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/frame_host/navigator_impl.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/frame_host/render_frame_host_manager_browsertest.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/site_instance_impl.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/browser/webui/web_ui_controller_factory_registry.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/public/common/url_constants.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/public/common/url_constants.h
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/public/common/url_utils.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/public/common/url_utils.h
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/public/test/navigation_simulator.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/test/content_browser_test_test.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/content/test/test_web_contents.cc
[modify] https://crrev.com/7fced7b524d0ea7a165b0686e8d459880e1639f5/tools/perf/core/stacktrace_unittest.py

Our students are going to chrome://quit to turn off their Chromebooks and hide what they were doing.  Our teachers would be very happy if this was resolved.  Thanks!

Is there a workaround?

I just checked and the bug indeed reproduces. In the code, these URLs are processed before being checked if they are blocked, specifically in:
https://cs.chromium.org/chromium/src/content/browser/frame_host/navigator_impl.cc?type=cs&sq=package:chromium&l=1053

Will try to create a new fix for this.