New issue
Advanced search Search tips
Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2015
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Disabling policy DisabledPluginsExceptions at machine level does not restrict policy at user level

Reported by, Feb 28 2014 Back to list

Issue description

Version of Google Chrome (Wrench-> About Google Chrome): 33
Version of MSI (if applicable):
Using group policy settings? Yes (but just locally as testing policy)

I am trying to disable the Java plugin via policy.  I am using gpedit.msc to edit policy on Windows 7 (I am just trying to figure out how to do this locally so I can advice what the domain policy should be).  I am using the Google provided AMD template from

At the Computer Configuration level(1) I ENABLE “Specify a list of disabled plug-ins” (the DisabledPlugins policy) and set an entry of "Java(TM)".  Going to chrome://plugins I see the Java plugin is greyed out, and going to Chrome says Java is disabled.  That's fine and as expected.

At the Computer Configuration level I DISABLE “Specify a list of plug-ins that the user can enable or disable” (the DisabledPluginsExceptions policy).

At the USER Configuration level(2) I ENABLE “Specify a list of plug-ins that the user can enable or disable” and set an entry of "Java(TM)".  When I go to chrome://plugins the Java plugin is NOT disabled, and going to the Java test site the Java plugin runs.

It seems setting DisabledPluginsExceptions to DISABLED at the COMPUTER level is equivalent to NOT CONFIGURING the policy, this means that at the USER level the DisabledPluginsExceptions policy can be set and Java be run.

It seems to me that if you are trying to block a plugin at the COMPUTER level then this should not be able to be overridden at the USER level.  Chrome should recognise that DisabledPluginsExceptions policy set to DISABLED should override policy set lower in the hierarchy. (I imagine the same needs to be done if the EnabledPlugins policy is set to DISABLED).

Note, if at the COMPUTER Configuration level I ENABLE “Specify a list of plug-ins that the user can enable or disable” and put in a junk value "aaa" (with the same DisabledPluginsExceptions policy set at the USER level to "Java(TM)"), then the COMPUTER policy does override the USER policy and the Java plugin does not work.

I haven't tested this at the Domain level of policy (I'm not able to).  But currently it seems like I am unable to block the use of the Java plugin in a way that the user cannot trivially override.

(1) In Local Group Policy Editor - Computer Configuration->Administrative Templates->Classic Administrative Templates->Google->Google Chrome
(2) In Local Group Policy Editor - User Configuration->Administrative Templates->Classic Administrative Templates->Google->Google Chrome
Labels: Needs-Feedback
This is working as intended. HKLM (machine) policy overrides HKCU (user) policy.

The problem is that "Disabled" means different things in the GPO editor depending on the policy type. For boolean policies, "Disabled" sets them to false. For everything else, "Disabled" is the same as "Not configured".

So if you want to set DisabledPluginsExceptions at the Machine level then you should set it to "Enabled" but leave the list empty. Does that work?

I think this could be fixed in the ADM template, because we can specify a value for when the policy is set to Enabled and another for Disabled. We don't use this second value, but we could use it to set empty strings, empty lists, etc. However, changing that now would potentially break existing deployments, so it's likely a no go.

Dave, does it work if you set DisabledPluginsExceptions to "Enabled" but leave the list empty at the machine level?
That was the first thing I tried.  Unfortunately the editor (gpedit.msc) doesn't let you enter a blank entry as a list entry.  You can only enter a 'space' but that seems like a poor solution.

I guess it's a matter of opinion, but I can imagine if you changed Disabled to mean an empty list than that is what people expect and so I don't see you breaking existing systems as much as making them work as expected.  Not sure if you guys have any data for this particular combination of policies?

Any other thoughts on a solution?
Labels: -Needs-Feedback
Status: Available (was: NULL)
A quick check at the ADM and ADMX syntax suggests that "Disabled" can set a value for string and integer values but not for lists.

We'll have to manually verify this, change the ADM template and see how the GPO editor behaves. Changing the semantics for existing deployments is risky at this stage, but I see the issue of setting "exception" policies at the USER level.

The team doesn't have cycles to look at this during this week. For the time being, you can just set the policy to "Enabled" at the machine level and set some value that won't match anything, like "no-such-plugin".

So I had a play with the ADMX file and this makes me think the way Disable works is a bug with Microsoft.  I tried specified a 'disabledValue' and 'disabledList' (separately) with an 'elements' value, but the disabled values weren't set when the policy was set to Disabled.  So changing the template doesn't seem like a starter.

Putting in a bogus value such as "no-such-plugin" into the DisabledPluginsException policy will work, but it's not a nice long term solution.

I can think of 2 other options:

1. Introduce a new policy, something like, DisallowPluginExceptions, and make it a machine level policy only so the user can't set it's value.  I'm guessing you don't want to make things more complicated though.

2. Don't allow any exceptions to override explicitly disabled plugins.  Looking at the reasoning for the DisallowPluginExceptions policy

"This policy is meant to allow for strict plugin blacklisting where the 'DisabledPlugins' list contains wildcarded entries like disable all plugins '*' or disable all Java plugins '*Java*' but the administrator wishes to enable some particular version like 'IcedTea Java 2.3'. This particular versions can be specified in this policy."

So DisallowPluginExceptions serves to allow a specific plugin where a regex plugin has been disabled.  So perhaps we can be intelligent about this, so let's define
- an explicit disabled plugin via DisabledPlugins e.g. "Java(TM)"
- a regex disabled plugin via DisabledPlugins e.g. "Java*"
- an explicitly allowed plugin via DisallowPluginExceptions e.g. "Java Deployment Toolkit"
- a regex allowed plugin plugin via DisallowPluginExceptions e.g. "Java Deployment Toolkit *"

The logic could be:
- an explicitly allowed plugin by a user CAN override a regex disabled plugin by an admin e.g. if DisabledPlugins="Java*" and DisallowPluginExceptions e.g. "Java Deployment Toolkit" then the named plugin runs.  This is what currently happens.
- an explicitly allowed plugin by a user CANNOT override an explicitly disabled plugin by an admin e.g. if DisabledPlugins="Java(TM)" and DisallowPluginExceptions e.g. "Java(TM)" then the named plugin doesn't run.  This is new, it means if an admin has explicitly named a plugin to be disabled, and the user is trying to enable that exact plugin, then that's not allowed.  If a user tries to enable a plugin file, but the plugin group has been disabled, then the plugin is still disabled.

The same logic would apply if DisallowPluginExceptions was a regex expression.

This would likely be backward compatible as the only new logic is if the DisabledPlugins is an explicit value, and DisallowPluginExceptions contains either the same value or a regex that includes the DisabledPlugins value.  Which is odd if set by an admin, but exactly what a user would do trying to bypass the policy.

From a security point of view this is reasonable, an explicit blacklisted plugin cannot be allowed.  The same logic should also apply to EnabledPlugins, as it is equally non-sensical for this to specify a value that is explicitly disabled.  Explicit blacklists should always take precedence over explicit whitelists or exceptions.
Labels: Enterprise-Triaged
Status: Assigned (was: NULL)
Joao, you aren't required to fix this, but since you've been engaging please finish triaging this issue.
Labels: -Enterprise-Triaged
Owner: ----
Status: Available (was: NULL)
As discussed, setting the policy to a bogus value such as "no-such-plugin" or even a space works.
Labels: Enterprise-Triaged
Status: WontFix (was: NULL)
As discussed, setting the policy to a bogus value such as "no-such-plugin" or even a space works.

Sign in to add a comment