Issue metadata
Sign in to add a comment
|
Developer Mode option chrome://extensions allows bypassing policy
Reported by
jani...@nv.ccsd.net,
Apr 4 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. go to chrome://extentions 2. select Developer Mode option 3. Install external app and modify/hack to bypass User Settings. What is the expected behavior? What went wrong? Allowing Developer Mode to be selected in chrome://extensions by students allows them to install homebrew apps and extensions that they are able to be further HACKED and bypass User Setting for the school district. Did this work before? N/A Chrome version: 56.0.2924.87 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 25.0 r0
,
Apr 4 2017
The code in UnpackedInstaller::IsLoadingUnpackedAllowed() includes the following comment: // If there is a "*" in the extension blacklist, then no extensions should be // allowed at all (except explicitly whitelisted extensions). This suggests that if the proper ExtensionInstallBlacklist policy is set, neither drag/drop of a .CRX nor manual "Load Unpacked Extension" will allow bypass of the policy.
,
Apr 4 2017
Two things: 1) How do you set the Extension Blacklist and will this prevent them from installing all Extensions or just the Extensions through Developer Mode? 2) We need to allow students to install some Extensions, we just don't want them to be able to install through Developer Mode or have the ability to HACK the ones they install.
,
Apr 4 2017
Thank you for providing more feedback. Adding requester "elawrence@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 4 2017
The Extension Blacklist is set via the Chrome policies (e.g. https://support.google.com/chrome/a/answer/187202?hl=en). You can set the list of allowed (and/or forced) extensions and block all other extensions. Simply blocking sideloading of extensions (e.g. drag/drop of CRX or via the "Load Unpacked Extension" button) probably wouldn't achieve your goals because the "attacker"/student could publish their extension to the Chrome store and install it that way. I'm not entirely sure what you mean about "have the ability to HACK the ones they install" -- a user with OS permissions to modify files on disk or run arbitrary programs can typically circumvent policy, as explained here: https://www.chromium.org/Home/chromium-security/security-faq#TOC-Why-aren-t-physically-local-attacks-in-Chrome-s-threat-model-
,
Apr 11 2017
This is a ChromeOS device yes? (per the screenshot) I don't see evidence of a bug here -- it seems to be WAI. If you need help setting policies, you can also follow up on the Chrome Help Forums.
,
Jul 19 2017
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Apr 4 2017Summary: Developer Mode option chrome://extensions allows bypassing policy (was: Disable Developer Mode option with-in chrome://extentions)