top | item 42981896

(no title)

retsl | 1 year ago

"For VS Code remote, the VS Code server is in the same trust boundary as the VS Code client. [...]

For Remote SSH: [...] A compromised remote could use the VS Code Remote connection to execute code on your local machine."

https://github.com/microsoft/vscode-remote-release/issues/66...

I wrote about it in a bit more detail a month ago because it seems to be a common misunderstanding: "VS Code Remote Dev and Dev Containers are not security boundaries" https://lets.re/blog/vscode-remote-dev/

discuss

order

mbreese|1 year ago

So this is why VSCode somewhat recently started asking if I trusted the authors/owners of remote folders.

kobalsky|1 year ago

That is why I exclusively run vscode in a virtual machine and use it through a browser tab on the host machine.

Luckily the web version is indistinguishable from the "native" version, they did a great work there.

Just share a folder with the VM and then bind mount whatever you want to edit at the time. No need to trust the author with all your credentials.

formerly_proven|1 year ago

Editing files on a server resulting in remote code execution apparently by design is such a classic 2004-Microsoft thing to do.

dunham|1 year ago

I see. I was intending to use a container to sandbox npm/yarn, it sounds like that is pointless.

npm scares me - if there is a way to sandbox it on a mac, I'd like to know.

retsl|1 year ago

Containers on MacOS are ran inside a Linux VM. If you ensure that the Linux VM doesn't have access to anything besides the required files/networks, that should be pretty secure.

Best case you go through the settings of Docker, Podman or whatever you use to limit integrations. Then, from within the VM and container see what networks, files, etc. you can reach to be sure.

raggi|1 year ago

deno has been somewhat pleasing in this space, it's not a perfect boundary though