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>

[hjrb]

Hello, is there a concrete time table when this "feature" will be released? I find it a little bit hard to understand what the current status is. There are many links to other issues. Can someone summarize the current situation?

[isidorn]

This feature will be released in VS Code Insiders this week. In VS Code stable start of December.
Group policy control for now only works in Windows. MacOS group policy support will be released Feb-March/

[hjrb]

Thank you a lot for the super fast feedback. Is there already a template ADMX file available so I can get familiar with it?

[agm-eratosth]

This feature will be released in VS Code Insiders this week. In VS Code stable start of December. Group policy control for now only works in Windows. MacOS group policy support will be released Feb-March/

Is there a timeline for linux support?

[isidorn]

Is there a timeline for linux support?

Right now - no. If you need linux group policy support it would be awesome if you create a new feature request and ping me on it. Then we can see how many enterprises need linux group policy support, and that will help us when we figure out prioritization.

Is there already a template ADMX file available so I can get familiar with it?

I am not sure the format of ADMX files, but this setting will just be JSON.stringify of what I proposed above.

[Gijsreyn]

@isidorn I know this feature has just been implemented, but I went through the PRs. I couldn't find any docs. Do you already have something on this? Would love to test it out!

[isidorn]

@Gijsreyn microsoft/vscode-docs@96d0cfc

Should be live on our docs webpage https://code.visualstudio.com/docs/setup/enterprise this week

[Gijsreyn]

You're quick with the responses, @isidorn . Thanks very much, greatly appreciated.

[hjrb]

I tested it briefly using the insiders build. I managed to successfully block a provider.
I'm not an expert on how to handle ADMX file. So do I need to change the file before I use Group Policy Management Console on the domain controller to set the list of allowed extensions or do i simply import the file and then set the value in the Group Policy Management Console?

[ntrogh]

Should be live on our docs webpage https://code.visualstudio.com/docs/setup/enterprise this week

Confirming that the docs for configuring extension allowlists are live.

[isidorn]

@ntrogh thank you!

Folk on this issue - let us know if there is something that the docs did not cover, and any other feedback you might have after using this feature (that is now launched and available in VS Code Stable).

[GitMensch]

LGTM in general.

Some feedback: t1he part "application setting" in https://code.visualstudio.com/docs/setup/enterprise#_configure-allowed-extensions got me confused, because for me that's quite different to "device management" (which is different per OS as well).

The biggest part under https://code.visualstudio.com/docs/setup/enterprise#_device-management that is unclear to me is how (if at all) those settings are taken into account for remote hosts. For example installing on a local REH after connecting to a Linux machine from command line is a server-side only part at first. Is the allow-list then still taken into account and some extensions possibly not loaded from the Windows Client when connecting?

[amitassaraf]

Good feature to finally be available. We've actually already have full discovery, governance, and risk for extensions for VSCode as part of our enterprise solution, and for all other IDEs. If you want this feature as a full solution I recommend checking extensiontotal.com 🥇