Extension policy interaction not behaving in expected manner |
||||||||||||||||||||||||||||||
Issue descriptionChrome Version: (copy from chrome://version) 64.0.3282.186 (Official Build) (64-bit) OS: (e.g. Win7, OSX 10.9.5, etc...) Win10 Version 1709 (build 16299.248) Test to see that interactions between whitelisted extensions and extensions restricted by permissions behaves in the way we expect --- that an extension should be blocked when permission restricted but then unblocked when added to whitelist Step 1: test that forced extension install of extension works Step 2: test that when you apply extension restricted by permission should then block extension (restricting notification permission) Step 3: test that when you add extension to the whitelist the extension should again work Extension Homegrown Timer app: 2hrtimer.crx AppID for Timer app: bcanfnleljfidkjhhfknjjiicdonddad What happens instead? Timer extension does not work after whitelisting with permission restricted. Please see following video that demonstrates what was experienced (note that it took me time to find an app that had a permission I could find to restrict -- I ended up on the 2hrtimer.crx) https://youtu.be/8F4mfBjiJJQ
,
Feb 28 2018
Hi Nick, Can you review the video and repro to see if there is a bug here or if we just need to update/clarify documentation?
,
Feb 28 2018
The whitelisting showing in the video is using the ExtensionInstallWhitelist policy. The ExtensionInstallWhitelist is part of the legacy extension policies along with ExtensionInstallBlacklist, ExtensionInstallForcelist, ExtensionInstallSources.
The newer ExtensionSettings policy is used in place of these legacy policies to offer new capabilities like blocking extension install by permission. This control can be set for individual extensions like in the policy below. The policy below means that if the Timer app contains the 'notification' permission it may not be installed.
{
"bcanfnleljfidkjhhfknjjiicdonddad": {
"blocked_permissions": [
"notifications"
]
}
}
With hundreds of thousands of extensions available specifying this for each extension doesn't scale. This is why we provide the ability to specify a default policy when an extension doesn't have one that applies specifically to it. This is set with the wildcard character '*'. The following policy will block the install of any extension with the 'notifications' permission.
{
"*": {
"blocked_permissions": [
"notifications"
]
}
}
To allow the Timer app we'll combine the default and per-extension/apps settings to get the following policy. This will allow the Timer app to be installed even though it uses the 'notifications' permission. All other extensions using the 'notifications' permission however will be blocked from install.
{
"*": {
"blocked_permissions": [
"notifications"
]
},
"bcanfnleljfidkjhhfknjjiicdonddad": {
"installation_mode": "allowed"
}
}
Since the default setting for 'installation_mode' is allowed, we can remove it from the policy and have he same effect.
{
"*": {
"blocked_permissions": [
"notifications"
]
},
"bcanfnleljfidkjhhfknjjiicdonddad": {}
}
Could you please re-test with the provided policy to see if you're still experiencing this issue?
,
Feb 28 2018
The default v.s. individual scope is detailed on the following support page https://support.google.com/chrome/a/answer/7514233?hl=en&ref_topic=7517516 May I ask what resources you used to set this policy? Was it mainly the text in the ADMX template itself? If so, we could include a link to the support page in the policy text itself. If you did see the support page previously, was there part of it that was particularly unclear that we should revisit?
,
Mar 1 2018
Hi -- the most important information that I did not know was that the Extension Management Settings policy supersedes or was not meant to interact with the "legacy" extensions. I suggest that this point should be more explicit in present documentation --- can "legacy" be more clearly defined or can the "legacy" extension descriptions be updated to be labeled as such in the policy list and in the ADMX descriptions and point to the ExtensionManagement policy? To your questions: May I ask what resources you used to set this policy? I used the Chrome policy list descriptions (which do not show that whitelist/blacklist/etc extensions are "legacy") Additionally used https://support.google.com/chrome/a/answer/7532015#permissions to get the syntax for the permission restriction. I did not look at the page you highlighted as I had a misinformed assumption that this policy would interact with the other extensions not supersede them: https://support.google.com/chrome/a/answer/7514233?hl=en&ref_topic=7517516 Was it mainly the text in the ADMX template itself? No - see above. If so, we could include a link to the support page in the policy text itself. If you did see the support page previously, was there part of it that was particularly unclear that we should revisit? See my feedback above as to how I got to this misunderstanding -- I think making it much more explicit as to what are legacy extensions in both policy list and the HC docs with more examples of syntax like what you described in your email above would help other enterprises who have previously used the legacy apps. The HC doc does not describe a path from legacy to the new extension policy more explicitly. This would be very helpful to see the complexity of this policy and how it should be used (perhaps an "if you used whitelist policy - then this is the syntax in extension management policy" for each legacy extension example)
,
Mar 1 2018
To clarify a typo -- just realized in the last paragraph I said "legacy apps", I meant to say "legacy extensions" of my previous post.
,
Mar 1 2018
I also tested your syntax recommendation and it wasn't exactly the scenario I was testing -- I was looking for a forced installation scenario -- either way I was unsuccessful in making it work.
Point to note -- the extension I'm using (2hrtimer.crx App ID: bcanfnleljfidkjhhfknjjiicdonddad) is a homegrown app and is not hosted in the CWS but on an external site.
Even so - when I use the following syntax for an extension hosted normally in CWS --- I would expect this to be able to force install an extension (gotomeeting extension App ID: mjdchcigpimjbnldeiiaakooipceanbo which is in the CWS) -- but it does not work.
Example 1: Syntax for the 2hrtimer force install with permission blocked (is there different syntax if the crx is hosted outside of the CWS?)
{"*":{"blocked_permissions":["notifications"]},"bcanfnleljfidkjhhfknjjiicdonddad":{"installation_mode":"force_installed"}}
Example 2: Syntax for the gotomeeting extension force install with no permission blocked (I would expect the behaviour to be that the extension force installs normally like the legacy extension forceinstall)
{"mjdchcigpimjbnldeiiaakooipceanbo":{"installation_mode":"force_installed"}}
In those scenarios tested -- the "legacy" extensions were not enabled.
,
Mar 2 2018
If you're using the installation_mode of force_installed or normal_installed you need to include the update_url to tell Chrome where to download the extension. Without this the policy is considered invalid and an error displayed on the chrome://policy page. Please try the following instead. Looks like I'll have to update the online validation page as it doesn't consider a missing update_url as an error.
{"*":{"blocked_permissions":["notifications"]},"bcanfnleljfidkjhhfknjjiicdonddad":{"installation_mode":"force_installed","update_url":"https://clients2.google.com/service/update2/crx"}}
,
Mar 2 2018
I tested the string and it worked for both an extension served in the CWS and also hosted outside of the CWS.
,
Mar 2 2018
Untriaged w/ owner -> Assigned
,
Apr 24 2018
Can this policy only be set via GPO today? Taking a look in cPanel, it does not look like we have the way to whitelist app after restricting via permission. While GPO works fine for browser, this would limit the capabilities of what's available to Chrome OS.
,
Apr 26 2018
So i have been doing various testing scenerios of the permission extension, in console, GPO and forced sign-in user(console). At a high level the block permission extension supersede all white list or force install no matter set in legacy policy or within the extension permissions. Also it maybe deceiving to an admin as some extension depending on how they are published state can install, but fails when blocked permissions trys to run are required I think enterprise customer have a different understanding and use case of how they would expect this to work. I can upload configs and screenshots i also noticed some other bugs related to this issue, Besides pulling policy and screen are their logs I can gather? Jeff
,
Apr 26 2018
#11: You can set this in cPanel following the instructions on the following URL under "Apps and Extensions > Block extensions by permission". https://support.google.com/a/answer/2657289?hl=en
,
Apr 26 2018
In this use case on GPO office and drive will can not be installed or used.
{
"*": {
"blocked_permissions": ["notifications", "storage", "syncFileSystem", "usb"]
},
"gmbmikajjgmnabiglmofipeabaddhgne": {
"installation_mode": "allowed"
},
"ndjpnladcallmjemlbaebfadecfhkepb": {
"installation_mode": "allowed"
},
"dpdmhfocilnekecfjgimjdeckachfbec": {
"installation_mode": "allowed"
}
}
,
Apr 26 2018
In the console it does not fully the extension permission and still implements primary legacy policy
"ExtensionInstallForcelist": {
"level": "mandatory",
"scope": "user",
"source": "sourceCloud",
"value": [ "jlhmfgmfgeifomenelglieieghnjghma;https://clients2.google.com/service/update2/crx", "knipolnnllmklapflnccelgolnpehhpl;https://clients2.google.com/service/update2/crx", "fceempjejlfaadkgdacpfhheknndlcjl;https://clients2.google.com/service/update2/crx", "pjkljhegncpnkpknbcohdijeoejaedia;https://clients2.google.com/service/update2/crx", "jndclpdbaamdhonoechobihbbiimdgai;https://clients2.google.com/service/update2/crx", "gmbmikajjgmnabiglmofipeabaddhgne;https://clients2.google.com/service/update2/crx", "apdfllckaahabafndbhieahigkjlhalf;https://clients2.google.com/service/update2/crx", "ejidjjhkpiempkbhmpbfngldlkglhimk;https://clients2.google.com/service/update2/crx" ]
},
"ExtensionSettings": {
"level": "mandatory",
"scope": "user",
"source": "sourceCloud",
"value": {
"*": {
"blocked_permissions": [ "fileBrowserHandler", "fileSystemProvider", "storage", "syncFileSystem", "usb" ],
"runtime_allowed_hosts": [ "https://clients2.google.com" ]
}
}
}
,
Apr 26 2018
Another example screenshot of drive app being block even though its force installed or allowed because of enabling permission blocking
,
Apr 27 2018
I complete more testing of extension permissions via GPO. By adding the update URL to install modes, and it seems to resolve respecting the whitelist apps and extensions declared. Only if you do not declare an install mode if will not require the update url.
Maybe we can brainstorm on how to improve the help center article for customer building these.
I guess either way, if a customer has 1000 apps to whitelist and would hope to minimize whitelisting efforts by allowing all apps and block a few permissions, they will have the IT admin overhead managing a large whitelist.
Also there is no way to implement this in the console for CrOS and signed in browser, as only the legacy policies really work and blocking permission in the console is a hard block. Ideally customer would just like to manage one policy and make it consistent across their deployment, like upload the JSON in the console.
I am going to try to test the policy on Mac next.
{
"*":{"installation_mode":"allowed", "blocked_permissions":["notifications","storage","syncFileSystem","usb"]},
"gmbmikajjgmnabiglmofipeabaddhgne":{
"installation_mode":"force_installed",
"update_url":"https://clients2.google.com/service/update2/crx"
},
"ndjpnladcallmjemlbaebfadecfhkepb":{
"installation_mode":"allowed",
"update_url":"https://clients2.google.com/service/update2/crx"
},
"dpdmhfocilnekecfjgimjdeckachfbec":{},
"blkboeaihdlecgdjjgkcabbacndbjibc":{}
}
|
||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||
Comment 1 by norikob@chromium.org
, Feb 28 2018