General Discussion on Workspace Trust Feature
Tyriar opened this issue · 42 comments
Trusted Workspace
The trusted workspaces concept is intended to centralize and unify a security conscious decision required by a variety of VS Code features. The easiest existing example to understand of this decision is with the ESLint extension. The ESLint extension will try to use the eslint module in the current folder that is opened in VS Code and execute code from it. Since you may have checked out a random repository from the web, this could be dangerous if the repository contains a corrupt eslint module. Notice that ESLint is not trying to be malicious, but rather, the repository/corrupt module is taking advantage of this automatic code execution.
With Trusted Workspaces, the user will be able to declare whether or not they trust the folder that is opened in VS Code before these features are executed.
Current Subscribers
Extensions
Extensions should use this guide to participate in workspace trust.
Tasks
Tasks will not execute in an untrusted workspace.
Status Bar Indication
A trusted state is indicated with a small green icon. An untrusted state is indicated with the icon and text.
Management
The following json editor is a stand-in for a more feature-rich editor. We intend to replace this soon.
Try it out
Enable the setting
Add "security.workspace.trust.enabled": true to your settings.json.
The rich editor was introduced last milestone to replace the JSON editor. Here is a screenshot of the 1st draft which will get some love soon.
Thanks for working on this feature. This will help extensions address the security issues around untrusted repositories in a more consistent and reliable way. A couple of questions:
-
It looks like the workspace trust setting is based on the folders. How will it work in multi-root workspaces? Should all the folders be trusted?
-
When a new folder (not yet trusted) is added to the already trusted workspace (by other extension or by a command), should the extension get deactivated or require trust again?
-
In case of our extension, the main concern is in the settings defined in the untrusted workspace/folder. So I ended up wrapping the WorkspaceConfiguration to filter out workspace/folder settings until users explicitly opt in (similar to
typescript.tsdk).
Benefit of this approach is that users can still use features from our extension without fully trust the workspace.
Even basic features like code navigation or symbol search in Go extension need a tool execution using settings. So I think it's better to offer those features if we can run the tool using user settings safely rather than completely stopping the features.
Ignoring values from workspace/folder(+language) settings using the WorkspaceConfiguration inspect api isn't impossible but still tedious. Since the trusted workspace concept is officially supported, can you offer a variation ofWorkspaceConfiguration.getthat ignores settings from untrusted workspace?
Is there a chance that this might make it as a normal feature into the next release?
I'm asking because we face a situation in the Julia extension where we essentially either need to roll something like this ourselves really quickly for security reasons, or wait until this ships in the core product and then we could just hook into this. Having some clarity about the schedule for this feature would allow us to make a better decision whether we should roll our own similar thing, or wait for this.
I think extensions having to opt-out of working in non-trusted workspaces is the wrong approach. It will do nothing for unmaintained extensions and extensions for which the author did not know about the trusted workspaces concept. This will likely give the user a false sense of security. Instead I think extensions should opt-in to working in non-trusted workspaces. While this will require more effort on the end of extension authors, which admittedly may make this impractical, it should drastically reduce the amount of extensions working in non-trusted workspaces that should only be exposed to trusted workspaces.
I think extensions having to opt-out of working in non-trusted workspaces is the wrong approach. It will do nothing for unmaintained extensions and extensions for which the author did not know about the trusted workspaces concept. This will likely give the user a false sense of security. Instead I think extensions should opt-in to working in non-trusted workspaces. While this will require more effort on the end of extension authors, which admittedly may make this impractical, it should drastically reduce the amount of extensions working in non-trusted workspaces that should only be exposed to trusted workspaces.
I think another possibility would be to give a badge or label in the marketplace to extensions which implement workspace trust. I can imagine an organization allowing only extensions implementing trust to be installed, this would make it far easier to find them.
@Tyriar @sbatten One question; does the above "Configuration Editing" being disabled mean that unless a workspace is trusted, settings from the workspace will not be applied? UPDATE: No, settings from untrusted workspaces still get applied.
I think generally speaking, in an untrusted workspace, maybe nothing within the .vscode folder should work--no settings, no tasks, no launch, no extensions. If that were implemented within VSCode it would do 80% of what the Docker extension needs to do in terms of enforcing trust, and more generally would probably apply a lot of "free" security for all extensions. Is this already the plan for implementation?
To give an example, the Docker extension allows extensive command customization of things like docker build etc. If settings in .vscode are applied regardless of trust, then we would need to inspect the setting values, and require trust if they come from the workspace, but not if they come from default/global. However, if VSCode itself refuses to apply settings from an untrusted workspace, then the Docker extension doesn't have to do any of that inspection--it comes for free.
This would also fix things like #120462.
@bwateratmsft The current thinking, yet to be implemented, is that workspace settings will not be applied by default in an untrusted workspace. This removes the need for extensions to worry about such attacks. The extension will be able to opt out of this and handle the settings appropriately if desired.
@sbatten Cool! For the Docker extension, that would mean it would only need to gate the Docker Build and Compose Up commands behind trust--saves us a lot of work.
Add "workspace.trustEnabled": true to your settings.json.
It doesn't work for the latest insiders build. (Commit: 01466cf, Date: 2021-04-12T05:17:32.143Z).
Are you switching to "security.workspace.trust.enabled"?
Correct. I have updated the original description.
A lot has changed since the original proposal was made; I've updated the original comment to remove some of the experiences that are no longer in play. Since the latest is available to test in insiders via the setting mentioned in the first comment, we recommend checking it out with your personal workflows and providing feedback.
How can you disable this feature? This appeared in VSCode Insiders for me today, and it automatically starts in Restricted Mode, and I have to manually select Trust. This feature is not present in the main update channel.
@kesu1, add this to your Settings:
"security.workspace.trust.enabled": false,I have a few questions.
- Is the current version of VSCode just accepting all, as if every folder is trusted?
- What does this protect against?
- Which files would contain the issues? files in .vscode?
Is the current version of VSCode just accepting all, as if every folder is trusted?
Yes
What does this protect against?
A specially crafted project causing malicious code to execute when being opened inside an editor.
Which files would contain the issues? files in .vscode?
It depends on which extensions you are using. Some extensions run code inside node_modules. Rust-analyzer for example by default runs build scripts as part of building the project when saving to report compile errors.
I don't think I have any build extensions.
I do have shell-check though. Is that something to worry about?
I wouldn't expect so.
Could you give some examples of extensions which could cause malicious code to be executed
@CleanMachine1 I'm an extension author (Dance), and Dance, among other things, has support for custom modes (similar to Vim). Users can configure commands that must be executed when entering or leaving a mode, i.e. to restore selections when moving back to a previous mode.
Someone could override this setting in a workspace to execute a malicious command when changing modes, which is pretty much invisible to the user.
Anyway, I'm now using this API to only allow overriding "sensitive" settings in workspace settings if said workspace is trusted.
VSCodeVim does not allow vim.insertModeKeyBindings to be set in the workspace. My guess is that it would be a security issue, since a bad user could remap any key to an arbitrary command in the settings.
Another example: the ESLint extension loads ESLint from node_modules. Since a malicious workspace may somehow change what is in node_modules (e.g. by overriding dependencies or by including it in Git), ESLint may load malicious scripts on start-up. Before this update, it showed a prompt to the user when a workspace was loaded for the first time to ensure the user trusted the workspace. With this update, this prompt is standardized, and extensions do not need to individually ask this.
A specially crafted project causing malicious code to execute when being opened inside an editor.
@kesu1, add this to your Settings:
"security.workspace.trust.enabled": false,
Can there be an option to just not 'trust' any workspace as a default, or maybe the pop up dialog can have a 'don't trust, stop asking me, and continue' option and stop prompting me each time I open a new subdir in a given workspace? It's quite annoying the way it's working at the moment. I've been prompted multiple times on this 1 project workspace today already... perhaps this is unintended behaviour?
The workspace trust prompt that is being shown on startup is intended to be shown once per workspace by default. If that is not the behaviour that you are seeing please let us know. You can use the security.workspace.trust.startupPrompt setting to control whether the prompt is being shown when the workspace is opened for the very first time:
"security.workspace.trust.startupPrompt": "never"
Is there a way to disable this feature? It's just bloating an otherwise fine code editor, and pointless to my work
@hwsamuel, disable security.workspace.trust.enabled
It is definately showing me this prompt every time vs code starts and I open a given workspace if I elect not to trust the workspace in question the previous time. ...and in one case it showed it to me multiple times within the same workspace during the same vs code executation instance when I was navigating around subdirectories within the project. Ultimately I do trust the workspace in question, but imo I don't think I should have to - to my knowledge I don't have anything that should be executing arbitrary files inside the project when I launch vs code? And if I do, I wish for that to never happen. This behaviour, automatically executing arbitrary code within the workspace directory on editor start, should be opt-in not opt-out if I disable the prompt, right?
edit: Just now I tried setting security.workspace.trust.startupPrompt to 'never' and vs code immediately prompted me to trust the open workspace again. I get what you're trying to do here but this needs to be reworked a bit I think before pushing it onto everyone
Also.. just wanted to share my 'lol' at the setting item 'Trust: Empty Window - Controls whether or not the empty window is trusted by default within VS Code' what even is this?
edit: Just now I tried setting security.workspace.trust.startupPrompt to 'never' and vs code immediately prompted me to trust the open workspace again. I get what you're trying to do here but this needs to be reworked a bit I think before pushing it onto everyone
This should not be the case.
Do you mind sharing the exact steps that you have performed so that I can create an issue tracking this?
"security.workspace.trust.startupPrompt": "never"
^ that doesn't work. For example, I open the file via Filezilla, and I still get the pop-up. I expect execution to be disabled without any prompt.
@sybrew, the "security.workspace.trust.startupPrompt" setting controls the workspace trust prompt when opening an untrusted folder the very first time. I believe that the prompt that you are seeing is related to opening an untrusted file in a trusted environment, but to be certain do you mind sharing the exact steps that you follow when seeing the prompt. Thank you!
Hello,
While the motivation for this is very well explained above, and it can certainly protect less experienced users, I suggest that one of these two options be considered:
- Ask users to explicitly opt-in for this feature, explaining why it's a good idea.
- Make it really easier to opt-out.
From a user's point of view, there's nothing worse than your trusted software behaving differently than before, with no explanation, especially when it just keeps bugging you (Y'see, I tend to trust my own workspaces 😊).
with the following in my project's settings.json file:
"security.workspace.trust.startupPrompt": "never",
"security.workspace.trust.enabled": false,...i'm still seeing a prompt with "Do you trust the authors of the files in this folder".
this is preventing my end-to-end tests from running to completion. is there a way to entirely disable this feature in this context?
edit: ah, i see there'a flag i can pass in --disable-workspace-trust (docs)
apologies for the noise 🙏
edit: Just now I tried setting security.workspace.trust.startupPrompt to 'never' and vs code immediately prompted me to trust the open workspace again. I get what you're trying to do here but this needs to be reworked a bit I think before pushing it onto everyone
This should not be the case. Do you mind sharing the exact steps that you have performed so that I can create an issue tracking this?
I think all we want is to stop coming this blue message
and "security.workspace.trust.startupPrompt to never" does not stop this. what can? The answer is:
"security.workspace.trust.banner": "never"
this option is not shown in (Preferences -> Setting) by default
First you should set it in "setting.json" file. The location:
Windows: APPDATA\Code\User\settings.json
macOS: HOME/Library/Application Support/Code/User/settings.json
Linux: HOME/.config/Code/User/settings.json
then add this line:
"security.workspace.trust.banner": "never",
Please be careful about semicolon of previous line. like the image (last line & semicolon of end of above line)
ONE THING MORE. If it didn't work or the line you wrote was greyed color like this image, Update you VS Code. My old VS Code (version 1.57) did not had the setting and this line start to work after update to version 1.62.
Please be aware: now the VS Code doesn't show the Blue message and still open all new files as "untrusted".
One use case that I have as a prof is to download and grade student submissions. I do this thousands of times per semester, and I really wish I had a checkbox to Not trust a parent folder once vs. only being able to blanket Trust the parent:
For me, I'd be find to not trust ~/Downloads, set that once, and never have to do this dance again.
Could that checkbox be altered to affect the parent for either the Yes or No case?
There needs to be a way to trust "just once" for the current open editor. I don't want to have to maintain a list of trusted folders.
This is a very noisy feature. Throwing up a modal every time a new folder is opened is annoying. Please use a sane default. One idea is to open everything untrusted and then have the user trust a folder if they want the addition features.
This feature is a piece of SxxT, could vscode just to be a quite, swift and silenced TEXT EDITOR or IDE only? This feature will prevent non-programmers to use vscode, they will ask for notepad++ or something else instead, even a computer HAS installed a vscode, because they do not understand what they should do to this dialog. Trust or untrust, why should I care?
As an IDE, no such kind of IDE such as visual studio or jetbrains has such fXXking idiot feature to annoying users, but they definitely do more than a vscode do, is that it?
Just do what vscode should do, leave other things to expertise softwares (such as anti-virus softwares), please!
Please use a sane default. One idea is to open everything untrusted and then have the user trust a folder if they want the addition features.
Many features get disabled with this, for example language support. If we did this without prompting, many users would not discover language support for Python for example and assume it's broken.
Trust or untrust, why should I care?
As an IDE, no such kind of IDE such as visual studio or jetbrains has such fXXking idiot feature to annoying users, but they definitely do more than a vscode do, is that it?
Just do what vscode should do, leave other things to expertise softwares (such as anti-virus softwares), please!
@Coresi7 the reason this feature exists it because we received several security vulnerability reports, both for core and for extensions. And what was starting to happen was core and extensions were all implementing their own system to cover this. This feature consolidates it so there is a single prompt and that's it. If it's annoying you can essentially disable it by checking this box:
For finer grained control, run the manage workspace trust command and add your C or / drive or whatever.
I agree it's unfortunate that we need this at all, but we (vscode core and 1st party extensions) have a hard requirement to not cause a potential remote code execution vulnerability upon the opening of a folder. It's pretty obvious why we need to do this.
@sbatten @lszomoru is there anything else to do on this issue? Are we for example considering a checkbox to just trust everything to help the class of users that don't care, or is that too heavy handed?
Yes, maybe devs and IT techs could understand this (but not all of devs or it guys), but users do not. They will complain vscode is hard to use, because they do not understand why. They even do not know how to install a plugin, or use settings, they care how fast it can be or how to make the fonts or words rendered correct and meaningful without install heavy text editor tool (such as an IDE, or office like document editor). For this part of users, they do never care about trust or not.
We can mark everything as untrusted by default, if users need to use a plugin or extension feature, give a hint that features are disabled, trust this workspace to enable them, should be better.
@Coresi7 that's why we link off to extensive docs. It's a complicated problem that needs to balance usability and discoverability and this is what we came up with after months of discussion. One of the main reasons it's not as you're suggesting is because VS Code isn't really that useful without workspace trust since so many things are turned off, so we ask immediately upon folder open. It actually is already kind of is as you ask actually as several features request workspace trust immediately upon folder open (tasks, git, terminal, python language smarts).
Again it's unfortunate it needs to exist, but it's there to protect users.
There are likely other feature requests that I did not account for, but reading through the recent discussion and cross-referencing with out feature requests, I am closing this item in favor of the individual issues per problem.
@Tyriar what did you mean by this?
For finer grained control, run the manage workspace trust command and add your C or / drive or whatever.
Is there a command like vscode --trust-workspace "~" that would trust that workspace without the prompt inside vscode?
@TamaMcGlinn open the command palette (f1 or cmd/ctrl+shift+p) and select manage workspace trust:
You can then add whatever directory you want to permanently trust to the list in the bottom. For example I trust C:\GitHub where I clone everything I trust, and C:\Playground where I don't necessarily:
