Open PowerWeb5 opened 6 years ago
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
So, any update on this?
https://github.com/microsoft/vscode/issues/84756#issuecomment-2157964224
@marcelsauer4711 They mentioned here ETA 6 months https://github.com/microsoft/vscode/issues/84756#issuecomment-2157964224
@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
@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 " )
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
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.
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
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:
When Updating Extensions, show users "Approve New Permissions for (ExtensionName)?" prompt
3. Extensions functioning with Optional Permissions denied
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:
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
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.
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.
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
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
5. Safety Reporting
6. Modify Permissions Anytime
7. Auto-Update options per Extension
8. Extension Categories Enhancements
Extension Type Categories benefits and use cases:
Show "Extension Type/Category" near the top of the Extension Details Page:
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:
Possible Additional Extension Categories / Subcategories could include
9. Specific Permission Types could include
On-Demand Document Actions
Automated Document Actions
On-Demand Non-Document Actions
Automated Non-Document Actions (or just "Automation")
Document Rendering (or Document/Editor Rendering/Display)
User Interface Extension permissions
File System Permissions
Networking (or Internet, or Web Service Use)
Open Files (as Document Tabs)
Auto-Save (Opened Documents)
Manage Document Tabs
Create New Documents (opened as Document Tabs)
Task Management
Source Control
Process Control
Full System Control
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:
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