search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
160.89k stars 28.22k forks source link

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

Open PowerWeb5 opened 6 years ago

PowerWeb5 commented 6 years ago

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:

image

(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

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?

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:

image

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

image

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

image

Firefox allowing managing Auto-Update behavior for installed extensions:

image

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

image

Labels

Suggested additional labels for this issue: install-update

Possible additional labels: api-proposal, extension-host

vscodebot[bot] commented 6 years ago

(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

PowerWeb5 commented 6 years ago

Thanks, @RMacfarlane, for tagging with suggested feature-request label.

PowerWeb5 commented 6 years ago

Any thoughts on this proposal for Extension Permissions & Update Management, especially from those who have been involved in extension management development and discussions in the past?

CC @RMacfarlane, @roblourens, @joaomoreno, @sandy081, @egamma, @Tyriar, @bpasero, @ramya-rao-a, @octref, @alexhass, @kasajian, @mjbvz, @chrmarti, @isidorn, @IlyaBiryukov, @FBoucher, @arhont375, @yume-chan, @gregvanl, @aeschli, @alexandrudima, @jrieken, @fabiospampinato, @chrisdias, @waderyan

yume-chan commented 6 years ago

  1. Chrome's extension permission system is a bad design. "Read your data on the websites you visited", how will the extension use the data? Google only cares about the registration fee, not the safety of their users. Mozilla used to require you to submit the source code of your extension to be reviewed. Microsoft Store will test your app's functionality by real human. Many vendors except Google don't prompt user what permissions the app/extension need, they won't put the responsibility on users.

  2. If you really want a permission system, the foundation of that is sandboxing. It must be possible to limit what the extension can do. But Code, which is based on Node.js, doesn't have such a thing. Extension can also depend on external components, written by any random technology. So the first thing to do is spending months to make a platform-dependent sandbox system with permission feature specified for Code. (When I'm writing this, I think running Code in a cross-platform virtual machine software is deadly simpler)

  3. After you successfully limit extensions to the active work space, the goal of permission system is protecting users' sensitive data. Can an extension only adding commands/tasks/debug configurations be harmful? For an IDE, the only sensitive data is: code In my opinion, splitting extensions by three characteristics is enough: Can read file, Can write file, Can connect to network One more thing: Can an extension call vscode extension api without user interaction. Most commands are only meaningful when invoked by user, maybe we can make it a permission.

  4. Update management is a good request

PowerWeb5 commented 6 years ago

Hi @yume-chan, Thanks for your feedback. Good points.

Though Chrome and Firefox aren't perfect when comes to notifying users of permissions, I think recently they have done a good job, and even disable extensions until user authorizes newly required permissions after an update (though without ability to reject a specific optional permission as proposed here).

In any case, Chrome and Firefox are at least a good reference as a starting place for UI and how this has been implemented (and considered critical to do so) elsewhere for extension management, though I've outlined a few ways I think this could be done a bit differently with VSCode.

Do you have any specific suggestions on other applications that allow install of extensions and require users to authorize permissions for those extensions (upon install or when new permissions are requested upon update) that you would suggest as a better reference than Chrome or Firefox?

PowerWeb5 commented 6 years ago

@yume-chan,

Read, write, networking, and automation (VSCode command use) are the critical basic permissions to support, but I believe there are others, as can see in those proposed.

Ability to limit many code extensions to just modifying contents shown in doc tab, allowing user to control if/when those edits are saved after seeing them should suffice for many extensions. I don't want extensions able to delete folders on hard drive or connecting to internet if it's a formatting or syntax extension as is the cast for most of the many I've installed.

Other extensions which just register a new action to manually invoke on open document via F1 or context menu (as are the majority of other extensions installed, eg for formatting, deleting duplicate lines, sorting lines, etc) shouldn't be using APIs to automate messing with project files or source control or invoking save/delete commands and so forth.

PowerWeb5 commented 6 years ago

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

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?

PowerWeb5 commented 6 years ago

Is this a possibility or something being considered currently?

Does anyone have any thoughts on sandboxing extensions and enabling users to manage permissions for them (or even auto-update permission, to start with)?

PowerWeb5 commented 6 years ago

@RMacfarlane, @roblourens, @joaomoreno, @sandy081, @egamma, @Tyriar, @bpasero, or @ramya-rao-a,

Is extension security sandboxing something you would be willing to consider for VSCode?

I've provided, in my previous reply, a list of Electron and Node.js VM projects which you might be able to integrate or use as a reference for how this could be achieved with VSCode.

I've detailed in this proposal how permission management could be exposed to users, similar to how it's been done with success for Chrome and Firefox, along with other suggested enhancements for extension auto-update options, prompts, and categorization.

Though it's been a month, I haven't had any feedback from any of the VSCode developers (just one user) so any comments here would be much appreciated.

Thanks, Dan

PowerWeb5 commented 5 years ago

@RMacfarlane, @roblourens, @joaomoreno, @sandy081, @egamma, @Tyriar, @bpasero, or @ramya-rao-a, and other vscode devs dealing with extension management,

Any update on whether this is being considered?

As shown in links provided, there are methods and frameworks that would allow extension sandboxing even with it being based on Electron.

damaon commented 5 years ago

The amount of trust/review needed is insane without basic sandboxing for extensions.

I agree with @yume-chan

In my opinion, splitting extensions by three characteristics is enough: Can read file, Can write file, Can connect to network

Are there any plans to implement it?

phil294 commented 5 years ago

Specifically

File Reading Read any file on disk, including those not opened as documents by the user.

is by far the most important security threat.

Please correct me if I'm wrong: Currently, any extension I use could plant malicious code into its next update, read all my ssh keys and upload them to their server without anyone noticing for ages. Electron actually offers sandboing capabilities but they are not enforced, allowing extensions full access to node.js and my file system. This is insane. I am glad to be using it containerized. Also, strange to know how few users actually care.

PowerWeb5 commented 4 years ago

Is VSCode extension sandboxing (for security and reliability) and extension permissions something that is being considered or can be considered by the VSCode team?

In addition to helping improve security of such extensions, sandboxing may also help improve reliability.

Potentially Preventing Current Widespread, Reoccurring Extension Host Crashing Occurring Now Across Many Extensions

This is especially important considering how frequently, especially recently, "Extension host terminated unexpectedly" has been occurring with a wide range of different extensions.

In such cases, due to lack of sandboxing or isolation, one extension will crash all other extensions. Even worse, one extension will crash a core part of the VS Code itself, the Extension Host, and require user to manually restart it.

Worse still, such extension host crash ends up preventing even the fact that the extension host had crashed from ever getting logged, as is occurring right now for me. It also prevents the original error which caused the crash from getting logged, as well as even what extension might have caused it, as even the relevant extension activation then fails to get logged as well, it seems.

As it stands now, it is nearly impossible to identify which extension was causing the crashes. Even one-by-one disabling of extensions isn't feasible, when there 170 extensions installed, and especially when it doesn't reliably occur on every single startup (just ever few startups). Hence why I have had to put up with frequent VS Code crashes on startup for months now before identifying the extension causing them.

Reliability Benefits and Critical Fixes Possible with Extension Isolation/Sandboxing

Though IMO something should be done in the VSCode extension host implementation to reduce the frequency of such issues (as well as logging improvements/fixes to identify the extension causing the issue), sandboxing could potentially isolate extensions in a way that would prevent them from crashing all other extensions, or at least prevent them from crashing core parts of the VSCode like the extension host itself.

This could also prevent that extension from causing critical diagnostic/error logging info from not occurring, making it actually possible to identify which extension had caused the crash – even if simply by looking at which extension failed to get activated, though likely with the ability to directly report to the user the problematic extension, prompting them to disable it. VSCode could potentially even optionally auto-disable such VSCode-crash inducing extensions it if such critical crashes occur a 2nd time within a short span of time.

800+ Outstanding Issue Reports and Many (Even Official) Extensions with Frequent, Reoccurring Extension Host Crashes

Many others are reporting the same, such as my recent report (ritwickdey/vscode-live-server#285) as well as #72476, #75267, MicrosoftDocs/live-share#1510, ritwickdey/vscode-live-server#285, Live Share Chat review, and 250+ other "Extension host terminated" bug reports just in the VSCode repo, 133 open issues under chrmarti/testissues and 850+ "Extension host terminated unexpectedly" bug reports across all GitHub VSCode extension repos.

A few of the extensions (including official/core/Microsoft extensions) which have frequent, reoccurring reports of causing of Extension Host Crashes include:

Live Share Audio, Live Server, Live Share Chat, Live Share, Live SASS Compiler, Typed Test, Java Language Server, and Mocha Sidebar.

And that is just based on one specific type of error that such sandboxing could potentially help address, in addition to other reliability and security benefits.

PowerWeb5 commented 4 years ago

See #79782 for more details about proposed use of Sandboxing for Reliability (more than Security) and how it may be needed especially now in light of the many recent reoccurring issues with many different popular extensions repeatedly crashing Extension Host (and therefore all other extensions) on VSCode startup, without any way to reliably or easily workaround for many extensions, let alone determine which extensions are causing the crashes.

marvingreenberg commented 4 years ago

In 2019, this really should be on the list. It isn't clear there is even an obvious way to REPORT a malicious extension easily (which is it's own nontrivial problem). The permission model @PowerAccess describes is complete for an implementation, but perhaps too complex for what would be presented to a user.

Something grouping of the fine grained permissions into end-user groups like,

Access local host Network Resources (127.0.0.1, ::1)
Access global Network Resources
Execute specific command (pylint.exe,pylint)
Execute any command
Execute background processes
Access files opened by vscode
Access any files

Perhaps with a details panel that would display the detailed permissions being granted.

@yume-chan says:

  But Code, which is based on Node.js, doesn't have such a thing." (a sandbox capability).

I understand that this is a VERY large undertaking: developing and documenting a permission model, developing or adopting a sandbox facility for node.js, and migrating all plugins. I also agree that other efforts in other domains (Chrome, Microsoft Store) are imperfect or require resources that are not appropriate for an open source undertaking like vscode. But in 2019 I fear that this is a real problem - malicious code being injected into random developer environments - that is probably already happening.

_As an aside, I wanted to be able to print from vscode, I found pdconsec.vscode-print Looking at the plugin I noticed that it was internationalized to ru, fr, en which put me (reasonably?) a little on edge. I examined the plugin code and it seems benign. But then I realized there could be modifications to any of the code under node_modules, and without a package-lock.json couldn't think of any reasonable way to verify the packages under nodemodules against the npm repository

mnini commented 4 years ago

Well, you can specify, which exact URL is extension allowed to, view extension's headers and content as user in chrome? I highly doubt, but VS code can be better allowing this to user.

Also it's just javascript, javascript is being able to parse... I mean if you have ASL or something like that of javascript, you can clearly see from the graph of functions, if somebody's keylogging, etc...

Narvey commented 4 years ago

This feature is vital. Without it, VS Code looks like a liability to the IT departments that might consider approving it! (think about trying to determine the risks of a wide variety of addons, and whether they will be stealing company secrets like proprietary code)

ChayimFriedman2 commented 4 years ago

Even if you trust your extensions, they, or their author's GitHub account, may be cracked, and as a result, malicious code would be injected to the extension. This happened multiple times to various npm modules - an attacker got access to some GitHub account which can accept PRs, injected malicious code that hijacks the user's password, and bumped up the minor version (e.g. 1.0.0 to 1.0.1), which triggers npm to automatically upgrade the package (because of this is non-breaking change). This happened to ESLint (https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes), and the dimensions of the damage can't even be estimated - probably any server in the world has been cracked. VSCode must prevent such thing from occurring. The attack needed full access to the file system. If this was a VSCode extension with the suggested security model, almost any user will install the suspected update.

gafarma89 commented 4 years ago

Is there any update/progress on this issue?

How can we gives access/read files and network permissions to all extensions? This a huge problem. How everyone accepts that ?!

I can not start VScode by blocking with any firewall or firejail, because I will not be able to update my extensions.

If you will not develop a permission manager feature, at least make a separate process for:

So we can block VScode process to connect internet manually (with firewall or firejail...).

Thank you

BettyJJ commented 3 years ago

It's shocking to see the VSCode team care so little about the security of their users.

mnini commented 3 years ago

I've been thinking for a while, that it's wrong microsoft bought ATOM, and it's true.

Microsoft's telemetry everywhere, and without security on extensions, it's like that you have extension, which communicates with server and send all code, and even receives what files to safe. You execute the code and it's over.

I think microsoft's been whole hacked in 30 minutes after their installed this ART OF CODE extension.

It's funny. There's no microsoft. Nobody hacked their update severs to ransomware before they coded in VS Code...

There's automatic "theBugger" in VS Code with extensions, maybe even without, that adds bugs to your code as you write it.

Haven't you noticed that tools on github for neural networks created by github are missing and being used to do something to programmers, which cannot finish anything?

Like IBM's so retarded they still reinstall OS on hacked bioses.

IT is doomed, let's use paper.

mnini commented 3 years ago

It's shocking to see the VSCode team care so little about the security of their users.

Microsoft's dead.

phil294 commented 2 years ago

https://code.visualstudio.com/updates/v1_59#_progress-for-electron-sandbox-support says

As we continue to make the VS Code workbench ready for enabling Electron's sandbox, ...

Does this mean this is a work in progress? Would this also apply to extensions? I could not find any information about this.

karam72 commented 2 years ago

Is there any news about this topic? All extensions can do anything. We use VSCode on enterprise and personal devices. This is very critical issue.

karam72 commented 2 years ago

Is there any update/progress on this issue?

How can we gives access/read files and network permissions to all extensions? This a huge problem. How everyone accepts that ?!

I can not start VScode by blocking with any firewall or firejail, because I will not be able to update my extensions.

If you will not develop a permission manager feature, at least make a separate process for:

* VScode updater

* extensions updater

* marketplace (extension download manager)

So we can block VScode process to connect internet manually (with firewall or firejail...).

Thank you

If extension permission will not develop why this idea is not implementing?

xsrvmy commented 2 years ago

Maybe this should be looked into again after the node-ipc incident.

axetroy commented 2 years ago

Maybe this should be looked into again after the node-ipc incident.

Yes, no sandbox, means running is unsafe code.

The NPM package has appeared several times, and the vscode extension will now appear later.

Imagine, open vscode a certain day, suddenly the file icon on the desktop has become a political slogan or even a virus icon

xsrvmy commented 2 years ago

The node-ipc attack straight up deleted files...

Actually what would sandboxing even look like? Extensions often, by nature, need to run external commands. Some extensions like rust-analyzer will actually download their own executable.

On a related note, there is also an issue with vscode's update management: if the license of an extension changes, it will still autoupdate. This could be a problem with company policies that may require, say, GPL software to be reviewed before being used.

karam72 commented 2 years ago

@xsrvmy

On a related note, there is also an issue with vscode's update management: if the license of an extension changes, it will still autoupdate. This could be a problem with company policies that may require, say, GPL software to be reviewed before being used.

VSCode already has this problem now. So nothing will change for this issue. Even though, what the companies doing about any app which support extensions? Like Firefox, LibreOffice, Eclipse...

Actually what would sandboxing even look like? Extensions often, by nature, need to run external commands. Some extensions like rust-analyzer will actually download their own executable.

For Flatpak there is a permission manager. As you can see on the following link, it can block inter-process communication. It is optional. https://flathub.org/apps/details/com.github.tchx84.Flatseal

junoatwork commented 2 years ago

Actually what would sandboxing even look like? Extensions often, by nature, need to run external commands. Some extensions like rust-analyzer will actually download their own executable.

That's fine, but in a sandbox model they would have to explicitly declare that they need these capabilities and users (or administrators) would have to explicitly allow it.

The Deno permissions model works like this:

Deno is secure by default. Therefore, unless you specifically enable it, a program run with Deno has no file, network, or environment access. Access to security sensitive functionality requires that permissions have been granted to an executing script through command line flags, or a runtime permission prompt.

For vscode extensions, it makes sense that capability permissions would be managed at extension install time. If an extension update required additional permissions, it would have to request them before using them.

karam72 commented 2 years ago

People start to use VSCodium instead of VSCode. The only way to get information from customers, is the extensions. Therefore microsoft team does not want this feature. Over wise people will disable network permissions :)

xsrvmy commented 2 years ago

Do official extensions even use their own networking to do telemetry? Or do they hook into vscode's built in telemetry?

And networking is one thing, messing with files is a totally different issue.

karam72 commented 2 years ago

Do official extensions even use their own networking to do telemetry? Or do they hook into vscode's built in telemetry?

And networking is one thing, messing with files is a totally different issue.

Officially, yes they use vscode 's built in.

juju4 commented 2 years ago

Browser extensions like Chrome and Firefox are much more mature and enterprise ready on this aspect. Both can enforce policies to block, allow or require extensions through GPO, MDM or other mechanisms. https://github.com/mozilla/policy-templates#extensions https://chromeenterprise.google/policies/#ExtensionInstallAllowlist https://support.google.com/chrome/a/answer/7532015?hl=en also webextension has granular control options with permissions and content-security-policy https://developer.chrome.com/docs/extensions/mv3/declare_permissions/ https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy

Eclipse seems to have this option cli: introduce exclude id list for extension-packs #9956, 2021, Merged https://github.com/eclipse-theia/theia/pull/9956

IMHO, it should be at least available as an option (be it for advanced users or enterprises) and ideally the default (people choosing to be less protected and taking responsibility).

On external commands, options could be

In a way, that's like Ms Office sandboxing and macros problem. Or mobile phone apps. Many people are not using advanced capabilities that would prevent use of sandboxing or extensions policies. Not sure if any survey/data available in this regard.

If you want your editor to be your operating system, yes, it can't have restrictions but that's for a limited population. for many, you want a text editor with some level of extras.

yume-chan commented 2 years ago

IMO only the extension allow list policy is worth a try.

WebExtensions' permissions can't really block malware, for example mining bitcoin in a Chrome extension doesn't need any permissions.

Not mentioning many extensions just declare "Read and change all your data on all websites", although Chrome has the setting to limit what the "all websites" means, it defaults to All sites.

image (Screenshot showing Microsoft Edge's extension management page having an option to limit which websites an extension can read and control)

Forgot to ask, do you have any data showing how many people are really reading the permission dialog before installing an extension?

To truly limit what an extension can do, since many extensions require running native executables, a virtual machine or container is the simplest and cross-platform solution. I really enjoy someday Code will have a 1GB installer and require 32GB of memory to run (no I don't).

image (A screenshot showing the size of Docker Desktop's installer for macOS is 576MB)

Anyway, as long as the extension can read your source code, and connect to the Internet, it can still upload all your company's code into the competitors' server. These permissions are so common, and the risk of supply-chain attacks means it can happen at any time.

In summary, the only method to ensure an extension's safety is to audit every line of code in it by humans. Making sure it's not doing anything bad, and not downloading or executing anything that can potentially be malicious. Then only allow those extensions to be installed.

kevin-he-01 commented 2 years ago

In summary, the only method to ensure an extension's safety is to audit every line of code in it by humans. Making sure it's not doing anything bad, and not downloading or executing anything that can potentially be malicious. Then only allow those extensions to be installed.

In addition, remember to do such an expensive audit every time the extension is updated to make sure malicious code is uploaded after a few benign releases, and disable auto update to make sure malware is not automatically installed. This is necessary based on what has happened to The Great Suspender Chrome extension. A malicious maintainer can kick in at any release.

Worse, the alleged source code for an extension (like a link to repository/GitHub) may not be what is actually installed. The only safe way is to clone the repo of an extension, inspect every line of the code (including the code used to build the extension), then build and install the extension manually (not via the VSCode marketplace).

However, if you are willing to do that, then you will be better off writing and maintaining your own extension instead of using those written by strangers.

IMO, since VSCode extensions are naturally privileged (should have read&write access to source code which implies arbitrary code execution), the best option is to be able to verify that the author of an extension is what is claimed to be, which is already implemented by the Verified Publisher badge. It is not perfect, but more feasible than many other options.

juju4 commented 2 years ago

Extended, regular and internal auditing is ideal but not possible for most organizations. Many can only rely on third-party audits. That can be badge or evaluation platform, be it shop or tool like https://crxcavator.io/ with the risk of single bias. Allow/Block/Require list is much more fit for all purpose be it organizations or advanced users and it could be by extension id, by author or whatever else criteria (signature, age/freshness, license, pack...). And for most companies, that should go in line with a centralized management of some key settings like update frequency, how long to wait for app restart and so on.

IMHO, it is not "naturally privileged", it depends.

shanewazabbas commented 2 years ago

Make vscode install extension straight from github (no more .vsix). Connect different versions to different commits. When an extension updates, vscode should let you have the option to directly view the pull request with the changes.

chriscerk commented 1 year ago

The "Extension Permissions" part of this feature would be extremely useful to scope the overall impact of extensions.

...like all software, extensions have bugs and feature gaps. So, for reading ease and artificial drama, let's use the term "bad extensions", which is an extension that might crash or simply show unwanted behavior. Fortunately, we designed VS Code with "bad" extensions in mind and therefore run them in a separate process. This isolation guarantees that VS Code keeps running, the cursor always blinks, and that you can always save your work. (source: VS Code - "Bad Extensions")

While both @command:workbench.action.reloadWindowWithExtensionsDisabled and @command:extension.bisect.start exist - these aren't sufficient in troubleshooting or mitigating all issues.

Apparently, some extensions permanently modify the VS Code installation (source: VS Code FAQ). It appears even reloading with extensions disabled wouldn't fix an issue caused by an extension which had permanently modified VS Code (until the next update).

see https://github.com/microsoft/vscode/issues/165171#issuecomment-1316688812 in which the integrated terminal fails to open. (root cause unclear)

This isolation guarantees that VS Code keeps running, the cursor always blinks, and that you can always save your work.

⭐ There doesn't appear to be true isolation of VS Code if some extensions can permanently modify the VS Code installation.

A tiny baby step in the right direction could even be some sort of flag marking which extensions are patching VS Code.

This feature is quite large and has been open for almost 4 and a half years. Is there any way we could break this down so it's more appetizing for the VS Code team?

dinofx commented 1 year ago

Both last week and ~5 months ago, our GH:E was severely impacted when a small number of users with a certain Microsoft VSCode extension installed were each issuing a large number of HTTP requests (around 1000/minute). Is there anything being considered that would limit or identify (to the developer) that an extension appears to be misbehaving? In these cases the network requests were likely due to a bug, but you could also imagine a compromised/malicious extension that is being used in a DDoS attack.

zm-cttae commented 1 year ago

Problem statement (Node.js security)

Positive use cases to support

Access to the filesystem and child processes via Node.js is used and acknowledged officially, but there isn't interest yet in replacing Node.js natives and locking down extensions further.

Proposal (Node.js sandboxing system)

The moment things are locked down, all natives used to access the disk aggressively error.

These Node.js modules would be barred from ever being used, full stop:

child_process, cluster, fs

EDIT: whitelist os because we don't have navigator in Node.js...

zm-cttae commented 1 year ago

I just figured out that there is a memory leak with lit-plugin extension and I reported it here: runem/lit-analyzer#298

This ended up taking up my complete RAM in my remote VM (I develop using remote SSH) leading to the VM rendering itself unresponsive and I had to reboot the VM again.

Now, while the reason for the memory leak is an issue with the extension, my concern is that VSCode must not allow extensions for consuming such huge amounts of memory. I already discussed this here but bringing this back up again since its critical to be addressed: #127728 (comment)

In summary, this is a feature request for VSCode to allow for throttling of resources used by extensions (with limits automatically set / specified by the user) - this will avoid such issues. Thanks.

Memory leak issue reported from @tvvignesh in #175249.

This can only be possible if we implement a sandbox for running extensions.

ghnp5 commented 1 year ago

@FBoucher - Apologies for the confusion, but what do Profiles have to do with Extension permissions?

zm-cttae commented 1 year ago

Agreed, also crossposting #180233 - "OS-level readwrite sandboxing for filesystem readwrites" Its a feature request needing 20 upvotes

FBoucher commented 1 year ago

@ghnp5 you are right! Apologies I was in the wrong tab! 😅

I rectified my previous message. Sorry for the confusion.

dudicoco commented 12 months ago

Since it doesn't seem like this is going to be fixed any time soon, does anyone have a workaround for the totally hackable and vulnerable extension system? (besides resorting to not installing extensions 😅)

phil294 commented 12 months ago

@dudicoco You can either containerize it or block network traffic, if that's enough for you. For containerization on Linux, there are different tools available like AppArmor and Firejail or even Docker or simply setting up a new user with limited file permissions. I am using x11docker to help with the latter: sudo x11docker --dbus --hostuser a_dedicated_user_account --nxagent --backend=host --clipboard -- code this does not use Docker, but if you remove the --backend=host, you can run a docker image instead too. Edit: To clarify: this will make vscode behave isolated and you cannot access your local folders. You'll have to work in the home directory of the a_dedicated_user_account user which you must have created beforehand. Or you set up some folder permissions e.g. under /usr/local so you can share it from both users.

Regarding network blocking, there's https://github.com/evilsocket/opensnitch for Linux and Little Snitch for MacOS.

Curious to see other solutions too.

dudicoco commented 12 months ago

Thanks @phil294, unfortunately i'm on mac and docker is too slow due to it running on VM (slow file sync issues).

Opensnitch might be a good workaround for network traffic, what about local filesystem manipulation though? Can extensions manipulate files outside of the current vscode workspace? Also there is the problem that extensions can modify vscode itself and modify user settings.

k06a commented 10 months ago

It's a shame VSCode extensions can make arbitrary damage to the host system.

markjlorenz commented 3 months ago

The devcontainers extension allows for both filesystem and network sandboxing. The containers provide the filesystem sandboxing, and by running DNS for the devcontainer through a pihole (setup in docker-compose), you get the network sandboxing.

.devcontainers/devcontainer.json

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/ubuntu
{
    "name": "your_container",
    // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
    "dockerComposeFile": "docker-compose.yml",
    "service": "devcontainer",
    "workspaceFolder": "/workspaces/your_workspace",

        // Features to add to the dev container. More info: https://containers.dev/features.
    "features": { },
    "customizations": {
        "vscode": {
          "extensions": []
        }
      },

    // Use 'forwardPorts' to make a list of ports inside the container available locally.
    // "forwardPorts": [],

    // Use 'postCreateCommand' to run commands after the container is created.
    // "postCreateCommand": "uname -a",

    // Configure tool-specific properties.
    // "customizations": {},

    // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
    // "remoteUser": "root"
}

.devcontainers/docker-compose.yml

version: '3.8'
services:
  devcontainer:
    image: mcr.microsoft.com/devcontainers/base:jammy
    # build:
    #   context: .
    #   dockerfile: Dockerfile
    volumes:
      - ../../:/workspaces/your_workspace
    command: sleep infinity
    networks:
      your_private_network:
        ipv4_address: 192.168.1.4
    dns:
      - 192.168.1.3
    depends_on:
      - pihole

  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    # For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
    # network_mode: host
    hostname: pihole
    ports:
      - "8080:80/tcp" # access the pihole admin at http://localhost:8080/admin
    environment:
      TZ: 'America/New York'
      WEBPASSWORD: 'SEKRET'
    # Volumes store your data between container upgrades
    # volumes:
    #   - './etc-pihole:/etc/pihole'
    #   - './etc-dnsmasq.d:/etc/dnsmasq.d'
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    restart: unless-stopped
    networks:
      your_private_netwwork:
        ipv4_address: 192.168.1.3

networks:
  your_private_netwwork:
    driver: bridge
    ipam:
      config:
        - subnet: "192.168.1.0/24"