[Feature Request] Extension Permissions, Security Sandboxing & Update Management Proposal

[PowerWeb5]

I believe that Visual Studio Code should support some kind of "Extension Permission Management", complete with prompts, warnings, opt-in, and opt-out, similar to what has been supported for some time now with Chrome, Firefox, and other browsers.

Reference Screenshot

I've provided, for reference, some screenshots showing Extension Permission and update prompts and management UIs in the below screenshot, as well as others torwards the end of this proposal.

Chrome prompting to approve additional permissions when updating an extension:

(See additional screenshots at the very bottom.)

Scope and Benefits

I have proposed, in detail here, how Extension Permissions management could function and be exposed to users, including descriptions of dialogs for prompting users to allow/deny permissions on extension install vs. updating, changes to Extensions Sidebar and Extension Details Marketplace pages, grouping/managing extensions by Category/Collection in VSCode, specific warnings and when to show them, types of permissions could define (and whether may default to opt-out or opt-in for them), APIs could provide, how extensions could operate with more limited or conditional functionality, and how could crowdsource extension safety reporting.

I'm also proposing that users can disable Auto-Update behavior for specific extensions, which, besides being useful in its own right, could allow users to stick with previous versions which require fewer permissions, manually review updates for higher-risk extensions, or avoid updating to problematic versions of extensions until issues are resolved.

Related Issues & Discussions

As discussed in Issue #9539 ("Visual Studio Code should update itself silently") regarding enabling silent, auto-updates of VSCode and Extensions) by @alexhass, @kasajian, myself and others, there are some security concerns regarding what permissions are granted to extensions when installing or updating them. As seen there, without such controls, some users aren't even comfortable installing many extensions, allowing them to auto-update once they have, or even allowing VSCode core itself to auto-update.

Proposed User Stories / Features for Extension Permissions Management

Specifically, I propose the following extension permission management features, prompts, and use cases:

1. Display Extension Permission requirements

1. Clearly labels what permissions are required by each extension in Extensions Details page, with Permission Name (plus Icon) shown underneath the Disable/Uninstall buttons for each permission required/requested.

2. Clearly label extension permissions, ideally via Icons (along with Name, Author, Description and Rating) in Extensions Sidebar (showing Installed and Available Extensions), at least as Icons next to either A) to left of # of Downloads (Cloud icon), B) to left of Settings (gear icon), or C) to right of Name and Version #, with them grayed out if denied

2. Prompt Users to Approve High-Risk Permissions

1. Notify user on extension install of potentially dangerous extension permissions and provide ability to opt-out of optional permissions or cancel install, by showing an "Approve Permissions for (ExtensionName)?" (or "Allow (ExtensionName) To?" or "Approve Extension Permissions") dialog:

   • Only show this dialog if more than just basic On-Demand Actions permissions are requested.
   • Provide VSCode options to skip this prompt if only other common, usually safe permissions as requested (like possibly "Auto-Complete"?)
   • "Approve" (or "Allow") and "Cancel Install" dialog buttons
   • Checkboxes (or toggle buttons) for each "Optional Permission" (with "(Optional") shown after permission name)
   • For Required Permissions, show Checked (but disabled, so can't modify) checkboxes shown next to required permissions, possibly with "(Required)" shown after permission name
   • [Maybe, Low Priority] If user attempts to uncheck a required permission, possibly could just suggest they "Don't install", "Disable" or "Install/Downgrade to Previous Version"

2. When Updating Extensions, show users "Approve New Permissions for (ExtensionName)?" prompt

   • Based on dialog shown when first installing
   • Only showing if/when there are new not-yet-approved permissions to review
   • Only shown if there are New Requested, New Required, or Now Required (previously optional and rejected) permissions which user hasn't already approved.
   • Show New (Not-yet-Approved or Now Required) permissions at the top
   • If permission was previously denied but is now Required instead of Optional, highlight it, and warn user may want to Cancel Update + Disable Auto-Update for that one extension instead.
   • Previously prompted permissions (whether or not previously approved, optional, required, etc.) are bottom, with space in between, so easy to review and modify here, but doesn't crowd the important changes.
   • Show dialog buttons: "Approve", "Skip Update" (only prompt again after next update), and "Never Update" (disabling auto-update).
   • [Advanced / Later / Maybe] Could ask user, after chose "Skip/Never Update", whether want to prompt again if/when required permissions change (optionally showing list of all New/Now Required permissions to check or uncheck waiting for, though may not be needed).

3. Extensions functioning with Optional Permissions denied

1. Extensions should be able to run with limited functionality when optional permissions are denied, yet be able to prompt user when try to use a feature disabled by denied permissions:

2. You could provide an API allowing extension to show the Approve Extension Permissions dialog together with a custom message (maybe even custom title too) together with API allowing extensions to check what permissions are currently approved for the extension

3. Possibly could limit extensions from checking permissions available to other extensions, in case would be security risk with them polling other extensions to find other extensions to automate/interact with as a workaround to their own denied permissions.

4. Provide "Never Ask Again" button so that a prompt is never shown again for an extension, possibly with option to disable prompts just for just a) specific feature (permission use case/prompt message), b) specific permission, or c) all permissions for this extension.

5. Can (disabled in VSCode Options) show status bar message and/or play error sound whenever attempt to use a feature (eg. hotkey, F1 action, etc.) unavailable due to denied permissions

6. Provide API making it flag an action or context menu item as requiring a permission so that will automatically show "(Disabled due to Permissions)" or "(Disabled)" after action names (eg. in F1 command line, menus, etc.), and/or show permission prompt if clicked (or hotkey is used) anyways.

4. Disable higher-risk permissions by default

1. Have dangerous permissions like Full File System Control disabled by default in permission prompts.
2. If required (vs. optional), can require user to manually check it before proceeding or warn user about the risks and how isn't needed for most extensions, and how may want to not proceed).
3. Can be based on selected "Extension Type/Category" (eg. Language Syntax, Language Syntax + Auto-Formatting, File Management, etc.)

5. Safety Reporting

1. Allow Users to Flag Extensions as Safe vs. Suspicious (in addition to Ratings / Reviews), to crowdsource security and review
2. Allowing reporting potentially malicious extensions for investigation
3. Possibly affects what, if any, type and severity of warnings are shown in Approve Permissions dialog
4. Possibly affects whether higher-risk optional permissions are enabled or disabled by default.

6. Modify Permissions Anytime

1. In Extension Sidebar, show "Enable/Disable (Permission Name) (Icon)" entry for each requested/required permission as menu items under the Gear icon (Settings menu showing Disable, Uninstall, etc. currently).
2. In Extensions Sidebar, ideally also allow clicking permission icons to enable/disable (gray out).
3. In Extensions Detail Page, allow clicking each Permission listed below the Disable, Uninstall, etc. buttons to Approve/Deny them.

7. Auto-Update options per Extension

1. Users could opt-out of Auto-Update for specific extensions, with toggle button next to Disable/Uninstall in Extensions Sidebar (under gear icon menu) and next to those buttons in Extensions Detail Page.
2. This could allow users to stick with previous versions before new high-risk permissions became required
3. This could allow avoiding updating to problematic versions of extensions until issues are resolved.
4. This could allow users to manually review/approve updates based on reviews and changelog for higher (security or reliability) risk extensions
5. This could be controlled per extension without disabling globally as may be desired by default for most extensions.
6. Can be set per extension to "Default" vs Auto-Update vs. Disable Automates, like with Firefox, with Default behavior controlled through global setting. Could provide Undo Update button or choose from version history (like with Chrome/Firefox extension stores) on extension details page, to enable rollback to previous version after an update causes issues, instead of just disabling until if/when ever fixed.

8. Extension Categories Enhancements

1. Extension Type Categories benefits and use cases:

   • Allow extensions to be browsed or filtered by category from within VSCode and more easily in marketplace, in addition to how are used as Collections in Marketplace currently, possibly allowing extensions to belong to multiple categories, and supporting subcategories.
   • Which permissions are selected by default in Approve Permissions dialog, and when warnings (for exceptionally high-risk, unusual permission requirements) are shown to user in that dialog can be used on the extension type.
   • This also makes it very clear to the user - without relying on them reviewing easy-to-overlook detailed permission requirements - at a glance what kind of permissions are likely to be required.
   • This can also be useful in general for helping users to find extensions, like done with Chrome and Firefox.
   • This can also make it very clear to users how advanced an extension is, with just Syntax Highlighting vs. Auto-Complete vs. Run/Debug, when trying to find an extension for a particular language.

2. Show "Extension Type/Category" near the top of the Extension Details Page:

   • Category Customizable by Author, but limited based on permissions, eg. can't classify File System control extension as "On-Demand Actions"
   • Showing this Category at either: A) to right of Extension Name/ID at top, in parenthesis, B) to right of Author Name, C) a separate Line below Author, D) to the left of the Permissions Names/Icons row, or E) a separate line above the Permissions row.
   • Allow Browsing and Filtering on Extensions website by Extension Type/Category

3. Group Extensions by Category in Extensions Sidebar

   With grouping enabled/disabled via Icon next to "Clear Extensions Input", possibly allowing Expand/Collapse Groups, with options to group by:

   • Extension Type/Category (overall, like Language Syntax, etc.)
   • Permission (eg. File System, Auto-Save, Auto-Complete, On-Demand Actions), with extensions able to be shown multiple times under multiple groups.

4. Possible Additional Extension Categories / Subcategories could include

   • Language Syntax
     • Highlighting, maybe even auto-complete prompts supports (if user always chooses/confirms what to insert, vs. arbitrary, automated modification of any document contents
   • Language Syntax & Auto-Format
     • If want as separate category with much higher expected (and by-default enabled) permissions, and if don't just allow extensions belong to a couple different categories simultaneously.
   • Auto-Format (Auto Document Actions)
   • Document Tabs Management
   • Document Actions
   • Menu Extensions
   • Automation
   • File Management
   • Web-Connected

9. Specific Permission Types could include

1. On-Demand Document Actions

   • Shown in F1 command line or newly added context, etc. menu actions which the user would have to choose to perform.
   • May not need permission (or at least don't show prompt) to register these kinds of actions.

2. Automated Document Actions

   • Automate executing own (or even other built-in or other extension) actions (from F1, context menu, etc.) in response to events, timer, etc.,
   • Possibly can split into separate permission for use of other extension and/or built-in actions.

3. On-Demand Non-Document Actions

   • Automated use of VSCode features which don't just affect document contents.

4. Automated Non-Document Actions (or just "Automation")

   • Use of Actions applying to more than just document content performed automatically instead of on-demand (via context menus or F1), such as instead based on event handling, timer, etc. or in response to certain types of document edits.

5. Document Rendering (or Document/Editor Rendering/Display)

   • For custom spelling underline, indicators, showing collapsible regions, etc.

6. User Interface Extension permissions

   • Toolbar
   • Context Menu
   • Menu Bar
   • Sidebar / Tool Windows
   • Statusbar

7. File System Permissions

   • Extension Data Files
     • Maybe allow extensions full control over files in folder only they have access to (except from other extensions without full file system control) without requiring approved permissions.
   • File Browsing
     • Read/list file and folder names (and possibly sizes, timestamps, etc.) for browsing.
   • File Reading
     • Read any file on disk, including those not opened as documents by the user.
   • File Modification
     • Modify or overwrite a file.
     • Provide warning in description for this and similar permissions that this is not typically necessary for language extensions where user can choose whether to save file or whether Auto-Save Permission should be granted instead.
     • Description / Tooltip: Warning: This is a potential dangerous permission usually not needed for most extensions (such as most Language Syntax extensions) which, when approved, allows the extension to delete, move, rename, create, read, and modify any files or folders on your system (Instead of just those installed with it or otherwise modify contents of opened document tabs user can choose to save), so you should only enable it for extensions you trust and may want to deny this permission when optional or cancel install of extensions which don’t allow opt-out, especially if seems like this wouldn't be necessary for the type of extension.
   • File Deletion
     • Delete any existing or newly created file on disk.

8. Networking (or Internet, or Web Service Use)

9. Open Files (as Document Tabs)

10. Auto-Save (Opened Documents)

    • If needed, can possibly split into separate permissions for Open Active Document (and only if allowed by document type/extension) vs. Auto-Save All Document Tabs.

11. Manage Document Tabs

    • Reorganize, rename, save, close, or create new (but not necessarily Open Existing File as New Tab, if have that as a separate permission).

12. Create New Documents (opened as Document Tabs)

13. Task Management

14. Source Control

15. Process Control

    • Interacting with processed had launched or with existing processes.

16. Full System Control

17. Launching Processes

    • Alternative Names: "Execute" or "Run/Debug Code/App" or "Launch / Run / Debug"

    • Description: Allow to start new processes or launch applications in background, such as is often required to Run, Build, or Debug code.

    • You could possibly allow extensions requiring this or similar permissions (or provide to any extension, if/when needed) the ability to save contents of an open document with unsaved changes to a temporary file, and provide the file path to that temp file to the extension - but without providing the extension the ability to modify/overwrite that temp file by default. This would reduce risk of a malicious extension being able to save and execute arbitrary code into a temp file without that code being first shown in the opened document tab.

    • You can even, if necessary, delay any process launching until X milliseconds after any extension-automated changes (eg. auto-formatting) made to opened document contents.

    • Possibly can restrict, as defined in extension manifest and shown in Extension Details Page, what executable names are allowed. Then, at worst, the extension would have to inject malicious code into an open script document and require user

    • Possibly can restrict (without requiring separate higher-risk permission) whether any variable command line args are allowed for it other than file name and pre-declared ones to prevent passing arbitrary code via command line to execute.

    • Possibly separate permission for launching processes for exe's that are just bundled with extension vs. already installed on the system.

10. Sandboxing Extensions

What, if anything, has already been done to provide or attempt extension sandboxing or security with VSCode?

As I understand, VSCode is based on Electrum which, by design, disables much of Chromium's facility for sandboxing to enable native API access. However, Electron and Node.js both have some facilities for sandboxing and security, and there are a few projects extending support for these, as detailed below:

Electron/Node.js Sandboxing/Security References and Options to Consider

• Electron's overview of security risks and options may be a useful reference for this discussion.
• Electron's sandbox options Would these be of any help here, or anything else described in above articles?
• Here is an Issue summing up progress of sandboxing support for Electron.
• Some tips on sandboxing and security with Electron Might the following be useful references for implementing Sandboxing in VSCode?
• @kwede's Electron Sandboxing example app / templatee for Electron app using sandboxing for security:
• Great summary of sandboxing and XSS with Electron, mentioning Brave browser as having developed or contributed code to support this.
• Might enableMixedSandbox() in VSCode be applicable or use of --enable-sandbox?
• Would disabling node integration (eg. via "new BrowserWindow({ webPreferences: { nodeIntegration: false } });") and/or Preload script + WebView - as both discussed in this Atom issue, as an example (though I understand VSCode isn't based on Atom) and as also suggested at Hackernoon- help here?
• Preload script based security,

Node.js / JavaScript Sandboxing Projects

Would any of Node.js's facilities for sandboxing / security possibly be applicable here, or any of the following projects providing sandboxing for Node.js or otherwise?

• Node.js built-in VM
• VM2 (from @patriksimek, like mentioned here)
• @gf3's Sandbox
• @auth0's SandboxJS
• electron-common-ipc
• Compute's Node.js sandboxing
• Google Caja

Additional Reference Screenshots

You can see some additional good examples of Extension Permission prompts and management in the screenshots below:

Chrome prompting user to confirm higher risk permissions (and in language very clear to the user), when installing an extension:

Chrome prompting user to enable additional requested permissions when updating an extension:

Chrome allowing modifying some permissions for installed extensions, like "Allow in incognito":

Firefox allowing managing Auto-Update behavior for installed extensions:

Firefox allowing changing permissions from sidebar for installed plugins, such as to control "Ask to Activate" behavior:

Labels

Suggested additional labels for this issue: install-update

Possible additional labels: api-proposal, extension-host

[marknuzz]

So, any update on this?

https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/

If you’re faced with the tradeoff between security and another priority, your answer is clear: Do security. -Satya Nadella, Chairman and CEO, Microsoft

https://medium.com/@amitassaraf/2-6-exposing-malicious-extensions-shocking-statistics-from-the-vs-code-marketplace-cf88b7a7f38f

[gjsjohnmurray]

So, any update on this?

https://github.com/microsoft/vscode/issues/84756#issuecomment-2157964224

[marcelsauer4711]

any news? https://medium.com/@amitassaraf/3-6-uncovering-design-flaws-in-the-visual-studio-code-marketplace-ea1d8e8b0171

[marknuzz]

any news? https://medium.com/@amitassaraf/3-6-uncovering-design-flaws-in-the-visual-studio-code-marketplace-ea1d8e8b0171

@marcelsauer4711 They mentioned here ETA 6 months https://github.com/microsoft/vscode/issues/84756#issuecomment-2157964224

[feeddageek]

@marknuzz No they didn't. The 6 months ETA is for a control mechanism for which extension can or cannot be installed. There is no ETA for Extension permissions and sandboxing. The public roadmap only mention "exploring sandboxing scenarios" for 2023/2024

[marknuzz]

[martin12333]

@markjlorenz https://github.com/microsoft/vscode/issues/52116#issuecomment-2028487842 devcontainers

@phil294 https://github.com/microsoft/vscode/issues/52116#issuecomment-1651206033

( I planned to use devcontainers for security sandboxing, ... but now I am very surprised by https://github.com/microsoft/vscode-remote-release/issues/6608 "Document the security model of VSCode Remote Development " )