Implement a policy-settings mechanism for approving/blocking extensions

[mike-myers-tob]

Hello! We (Trail of Bits Engineering Team) have been asked by one of our clients to contribute a feature to Visual Studio Code, and before we even begin we wanted to introduce ourselves and our plan and get feedback on (or approval for) our plan from the core maintainers of this repo. The proposed changes are to how the editor interfaces with the Extensions Marketplace, so it will only be useful if the changes can be upstreamed. In fact, we may need to coordinate with the VSCode open-source maintainers to even test builds that integrate the Extension Marketplace, present only in Microsoft builds of VSCode. We would appreciate your feedback on how/whether to proceed.

Feature Request

Enhance VSCode with the basic features for extension management:

• The ability to define an extension update policy
  • The policy would include a setting whether to allow side-loading of extensions (as VSIX files)
• With this policy, control whether VSCode can install, update, or load/run any given extension
  • Blacklist by extension ID
  • Whitelist by extension ID
• Pinning an extension to a particular version, allowing its continued use or the installation of that version, but preventing an update
• Prevent the use of extensions newer than some specified age (allowing for a “cooling off period” for new or untested extensions)

We plan to implement the extension management policy using an approach modeled on the extension management policy features in Google Chrome (and later by Mozilla, who based the extension management model of Firefox heavily on the one in Chrome), but without (at this time) its concept of a per-extension permissions model.

Deployment of the extension management policy to the managed systems would be handled out-of-band by the system's administrator, but it would be included within or referenced from the user's settings.json file. Right now we're not proposing to add any special controls to the settings editor UI of VSCode for editing this extension management policy. The policy will only be editable as JSON, as many other advanced features in VSCode are currently edited.

We acknowledge that, for the time being, this file is within control of the user. For now, we're going to ignore that (it is tracked in #27972)

Proposed UI changes

• Ensure that the VSCode extension UI elements presented to the user explain that an extension is blacklisted by their policy, and/or indicate such with a visual change. User should still be able to see blacklisted extensions in the marketplace, but just have their ability to install them blocked with a message (a configurable message also defined in the policy, with a clickable URL for more information and help), such as “this extension has been blocked by your policy; ask your admin.”
• Ensure that the VSCode extension marketplace UI indicates to the user when only certain versions of the extension are blocked. In this case, the installable version should be indicated, and a visual change in the UI should indicate the relevant release notes for that version.

Related Issues

• Feature Request: extension permissions, security sandboxing, and update management
• [Feature Request] - Extension Dating & Timestamps of last updates. #70736

Client sponsor

Our client, who has agreed to participate in this discussion, is @zabicki-stripe

[sandy081]

Appreciated for the detailed description of your requirement. To start with, one of the requested features is already supported. Pinning an extension to a particular version, allowing its continued use or the installation of that version, but preventing an update. User can pin to a specific version of an extension. Some of the features are not common and not frequently asked like disabling side loading, cooling off period.

I would say overall it is a big feature and generally not considered for external contribution. But if you are super keen on this, you can think of going with one by one.

[zabicki-stripe]

Hi Sandeep, Thank you for that context. It's quite helpful. If we split this into three contributions (allowlist, denylist, and cooling off period) do you think that these features would be approved? Thanks, Roman

…

On Mon, Nov 18, 2019 at 4:17 AM Sandeep Somavarapu ***@***.***> wrote: Appreciated for the detailed description of your requirement. To start with, one of the requested features is already supported. Pinning an extension to a particular version, allowing its continued use or the installation of that version, but preventing an update. User can pin to a specific version of an extension. Some of the features are not common and not frequently asked like disabling side loading, cooling off period. I would say overall it is a big feature and generally not considered for external contribution. But if you are super keen on this, you can think of going with one by one. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#84756?email_source=notifications&email_token=AL6TDYMM4D2TVNYGCUXTVO3QUJTRXA5CNFSM4JNEKII2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEJ5SLQ#issuecomment-554948910>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL6TDYK2CXLUSGI3BW2JPODQUJTRXANCNFSM4JNEKIIQ> .

[sandy081]

Depends on how complex each feature is going to be. But PRs are always welcome.

[mike-myers-tob]

@sandy081 what would you recommend we do in order to ensure that our contribution is accepted and merged in due time? I see there are many PRs going back several years, so some PRs are not welcome. We just want to know if these are specifically features that would be merged, if we completed a PR.

[sandy081]

You can start with

The policy would include a setting whether to allow side-loading of extensions (as VSIX files)

[vscodebot]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodebot]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[chrisdias]

Providing organizational level security is on our 2020 roadmap (Make consumption of extensions more secure...) so this is a good topic, thank you.

As @sandy081 mentions this is a significant feature area that we want to allocate time and resources for to do a comprehensive design and implementation, which makes it difficult right now to accept external contributions.

Per our roadmap, you can expect that we will look at this over the next 6-12 months.

[ks0411]

Hello, @chrisdias my customer is also keen to see this available as they rolled out the ADS in their corp but they want to control what users can install and managed centrally by policies. So that users dont miss use the extensions for data exfiltration or code leakage. Any further update on this would be great as the last comment is 2.5 yr old , i like to know what is the latest.
Thanks

[emilkloeden]

Hello.

I represent a small company 50-100 employees, with an internal development team comprising approx. 10-15 developers, testers and business intelligence users who all use Visual Studio Code. We have two goals that I'd like to address: to obtain a degree of consistency of extensions installed across devices, and the facility to control that centrally. To that end I had the bright idea of creating a feature request only to learn that this request already exists (and has for three years 🙄😄). Nevertheless, I was asked to share our use case here :).

Having an allow-list policy would enable us to limit the set of extensions that can be installed across the workplace in a simple-to-manage manner, however a model similar to Firefox's ExtensionSettings policy would allow us to explicitly control the entire set (noting that only the 'installation_mode' and possibly 'blocked_install_message' properties might be appropriate here).

Firefox example

{
  "*": {
    "blocked_install_message": "Custom error message.",
    "install_sources": ["https://yourwebsite.com/*"],
    "installation_mode": "blocked",
    "allowed_types": ["extension"]
  },
  "[email protected]": {
    "installation_mode": "force_installed",
    "install_url": "https://addons.mozilla.org/firefox/downloads/latest/ublock-origin/latest.xpi"
  },
  "[email protected]": {
    "installation_mode": "allowed"
  }
}

Possible VS Code example

{
  "*": {
    "blocked_install_message": "This extension has been blocked by your organisation.",
    "installation_mode": "blocked"
  },
  "ms-python.python": {
    "installation_mode": "force_installed"
  },
  "vscodevim.vim": {
    "installation_mode": "allowed"
  }
}

To date we have addressed our requirements by installing extensions to a non-user-writable location and setting the (undocumented - I believe) VSCODE_EXTENSIONS environment variable to point to that folder - but this is brittle at best.

Thanks for your time.

[o-l-a-v]

I created a duplicate issue ( #170840 ), I'll bring what I wrote there to this discussion.

---

As the VSCode marketplace does not seem to be sufficiently regulated from a security point of view:

• https://www.bleepingcomputer.com/news/microsoft/vscode-marketplace-can-be-abused-to-host-malicious-extensions/
• https://devclass.com/2023/01/09/researchers-demonstrate-a-thousand-installs-of-fake-vs-code-extension-in-48-hours/
• https://thehackernews.com/2023/01/hackers-distributing-malicious-visual.html

It would be great with ADMX policies for specifying extension policies, like:

• Allowed sources (VSCode Marketplace vs. other marketplaces (?) vs. sideload).
• Preaccepted extensions / whitelist:
  • A list of extensions from a source that are allowed to be installed.
  • Maybe even preaccepted publishers, like Microsoft, to make the management overhead smaller.

---

ATM, update mode seems to be the only thing one can control with VSCode.

VSCode.admx from VSCode v1.74.2

<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions revision="1.1" schemaVersion="1.0">
	<policyNamespaces>
		<target prefix="VSCode" namespace="Microsoft.Policies.VSCode" />
	</policyNamespaces>
	<resources minRequiredRevision="1.0" />
	<supportedOn>
		<definitions>
			<definition name="Supported_1_67" displayName="$(string.Supported_1_67)" />
		</definitions>
	</supportedOn>
	<categories>
		<category displayName="$(string.Application)" name="Application" />
		<category displayName="$(string.Category_updateConfigurationTitle)" name="updateConfigurationTitle"><parentCategory ref="Application" /></category>
	</categories>
	<policies>
		<policy name="UpdateMode" class="Both" displayName="$(string.UpdateMode)" explainText="$(string.UpdateMode_updateMode)" key="Software\Policies\Microsoft\VSCode" presentation="$(presentation.UpdateMode)">
			<parentCategory ref="updateConfigurationTitle" />
			<supportedOn ref="Supported_1_67" />
			<elements>
		<enum id="UpdateMode" valueName="UpdateMode">
			<item displayName="$(string.UpdateMode_none)"><value><string>none</string></value></item>
			<item displayName="$(string.UpdateMode_manual)"><value><string>manual</string></value></item>
			<item displayName="$(string.UpdateMode_start)"><value><string>start</string></value></item>
			<item displayName="$(string.UpdateMode_default)"><value><string>default</string></value></item>
		</enum>
			</elements>
		</policy>
	</policies>
</policyDefinitions>

[isidorn]

Thank you, this is super useful!

Would love to hear from others @CW-Willow @StephanGa @rowillia

[CW-Willow]

[Yeah, that got chewed nicely by GitHub email, sorry]

Speaking for ClassWallet,

We wouldn't use a blocklist ever. I don't know of a security framework that likes allow-all-except approaches, but we're up to our necks in StateRamp here. I can see it being useful at some companies where there's a 'bad' extension in the news that's a threat that you might want to dig out, but what about the other million on the store? If you're going to the trouble of managing endpoints and policy centrally, you're probably going deny-all-except every time.

Version control might be a good/better remedy if there's a dangerous version of something, but it's probably better solved by forcing an upgrade (or other mitigation for a while). As I mentioned before, if you can get super granular over versions, great, but it's not a huge deal; minimum version is fine for CW. Force install option of the latest version (per extension) becomes very useful as a check on startup occasionally.

All in all, what Chrome/Edge does with its extensions when you enable management is pretty much what's desired: Allowlist, minimum version, force install option.

I'd like to reiterate the additional ask to be able to customize messages on the store if managed, and at startup for the user if something is disabled. Save a lot of pain to the support desk.

We're a Windows shop. Intune.

Hope it helps. Thanks,
~W

[GitMensch]

The second example - allowList with negation - is totally fine. And if one _really_ would want, this can be used as blockList as well # allow all * # block all from bad and copilot !bad.* !github.copilot

[isidorn]

Great feedback, thank you!
Let's wait until Monday so more feedback trickles in, and then we will propose the solution that we will work on in the Nov milestone.

[GitMensch]

[...] One big open question, because this is planned as policy: How would you ensure that a user cannot override it?

Of course that list should apply for all of "marketplace", "from vsix inside vscode" and "from vsix using the command line".

That's still open and unclear to me.

If you add that as a normal setting, then any user code override it.
Obviously: if someone has the option to use a portable version of vscode, then that a policy.json won't apply any more.

If you add that to product.json, then this applies only to environments that are installed as system-install (expecting that users don't have the right to update it). If that is done, then a policy.json or similar should be used, because product.json is overwritten on updates. ... but come to think of it - a "system provided additional product.json that is merged" last (similar to #129764 which even could be integrated as well to solve another issue)" could help - if the system-provided comes "last" it may solve both issues (a user could never override that, even with portable versions and it could stay at one single place which is commonly not user-writable).

[isidorn]

@GitMensch https://code.visualstudio.com/docs/setup/enterprise#_group-policy-on-windows

So this would first only be allowed on Windows through group policy. But we would add macOS support in the next couple of milestones.

[GitMensch]

So this would first only be allowed on Windows through group policy.

:-(

But from your link the effect is the right thing and it is reasonable to use the group policies on Windows (even though I don't need to handle those any more myself). With the effect on the client side "overriding settings defined anywhere" I get that this would also work as expected with those clients connecting to GNU/Linux over SSH. Is that so?

Are the existing PolicyDefinitions online anywhere?

I hope that, as soon as macOS support is added, this may also work on GNU/Linux clients. It should easily work the same way if this would be handled via files.

[ryanewtaylor]

Looking forward to this, as this is a capability we need for our client.

I do not feel we need an explicit deny list in our case. Blocked by default and only allowing extensions in the allowlist is sufficient.

1. Is there a need to say "allow all versions of an extension"?
   • Yes.
2. Is there a need to say "allow all versions higher than a specific number"
   • Yes. To ensure extensions with critical vulnerabilities aren't installed.
3. Is there a need to say "allow all extensions from a specific publisher"
   • Yes. This would be helpful for trusted publishers like Microsoft

On specifying versions, using npm semantics would be helpful. It's already well defined.

• version - match exactly
• ~version - allow patch upgrades
• ^version - allow minor upgrades
• >version - greater than
• and so on...

If existing extensions no longer meet the requirements due to a policy update the extensions should be disabled, uninstalled, or updated automatically.

[isidorn]

Thank you all for your great feedback! @sandy081 and me iterated on this, and we came up with the following proposed structure

"extensions.allowed": {

        // Allow all extensions from microsoft publisher. If the key does not have a . that means it is a publisher id
        "microsoft": true,

        // Allow all extensions from github publisher
        "github": true,

        // Allow prettier extension
        "esbenp.prettier-vscode": true,

        // Do not allow docker extension
        "ms-azuretools.vscode-docker": false,

        // Allow only versions 3.0.0 of the eslint extension
        "dbaeumer.vscode-eslint": ["3.0.0"],

        // Allow versions "3.0.0", "4.2.3", "4.1.2" of the figma extension
        "figma.figma-vscode-extension": ["3.0.0", "4.2.3", "4.1.2"]

        // Allow versions "5.0.0" on win and mac of platform specific rust extension
        "rust-lang.rust-analyzer": ["5.0.0@win32-x64", "5.0.0@darwin-x64"]

        // Allow only stable versions from vscode-pull-request-github publisher
        "github.vscode-pull-request-github": "stable",

        // Allow only stable versions from redhat publisher
        "redhat": "stable",
    }

All extensions not listed here would not be allowed.

Notice the following:

• We decided to not support extensions ranges since we believe that is asking for trouble. An extension author can always publish a new version in the range, that might not be approved by your enterprise. So each version has to be explicitly listed
• We are supporting specifying platform specific versions using the @ notations. This will give your companies exact control over the allowed extension version
• If the key does not have a . we treat it as a publisher, and the rule applies for all extensions from that publisher
• The more specific key wins. So "microsoft": true and "microsoft.cplusplus":false all Microsoft extenions will be allowed except C++
• For the Windows group policy - the value set there will be this object json stringified.
• The value of each key is true | false | "stable" | array of string versions

You can also try it out with VS Code Insiders from next week, to see the full experience.
Please let us know what you think, and if this would work for your organization.
Thank you 🙏

[ckrueger1979]

For the Windows group policy - the value set there will be this object json stringified.

Please provide a validator

[GitMensch]

That's a good result, thanks for updating this issue as well. The additional (stable/platform) is also nice. I personally still feel that either a range or a >= / + option is necessary. The main reason is that I don't have the time to monitor and review dozens of extension updates, so they will either not be allowed for quite some time or I'm going to set those extensions to "true" instead.

[jvilk-stripe]

At Stripe, we approve of this design; it meets our requirements.

I did have one additional thought on a different matter. Previously, we discussed wanting to be able to configure the message or URL that appears in the marketplace for blocked/unapproved extensions. It would be really cool if this message or URL could be templated with the extension ID and version so that we can link directly to a filled out internal approval form.

[janssen92]

Great work! You solved a lot potential security issues with this!

Only thing that still requires manual work is ensuring security patches are applied by updating the allowed version. Would it be possible to have a "latest" option? Or is that implied when using "true"?

Alternative I would create a script to update the whitelist automatically, e.g. weekly, is there a good API at the extension server for this?

[isidorn]

Thank you very much for your feedback.

@ckrueger1979 the validator will basically be admin can paste the JSON string in the settings.json file on his machine. If there are no errors, it is good.

@GitMensch what company are you representing? Does your company have security concerns about a publisher deploying an extension version in your range that you did not review?

@jvilk-stripe Let's take that a separate feature request on top of this. Can you please file a new issue in this repo and ping me @isidorn on it

@janssen92 no, using "true" does not mean latest, it just means any extension version is allowed. Would "latest" mean "latest release version of the extension", or "any latest version of the extension including pre-release".

[isidorn]

@janssen92 discussed a bit with @sandy081 and we think this can be achieved by us making extensions.autoUpdate also group policy controlled. That way by putting "true" and autoUpdate to on, all the developers will be auto updated to latest extension version. Would that work?

[GitMensch]

If this considers both stable (latest stable) and true (latest anything), then this would be ok - but I'd still suggest to keep this in one place, adding "latest-stable" and "latest" to the version options. Am 22. November 2024 10:35:41 MEZ schrieb Isidor Nikolic ***@***.***>:

…

@janssen92 discussed a bit with @sandy081 and we think this can be achieved by us making extensions.autoUpdate also group policy controlled. That way by putting "true" and autoUpdate to on, all the developers will be auto updated to latest extension version. Would that work? -- Reply to this email directly or view it on GitHub: #84756 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[GitMensch]

Working in the banking sector... And "no", *if* there's a range configured then this range would be already considered "checked" - possibly there wouldn't be too many extensions configured "open" (themes likely would as they cannot do any harm... or can they "phone home"?)

[jvilk-stripe]

@isidorn Done! I created #234444 to capture our request for a templated denylist message, or, if that is not feasible, a templated URL put somewhere that the engineer can click for more info.

I encourage others who were interested in this feature (like @CW-Willow) to upvote and/or comment on it.