On: VSCode’s SSH agent is bananas

[retsl]

"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/

[mbreese → retsl]

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

[kobalsky → mbreese]

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 → retsl]

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

[dunham → retsl]

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.

[mdaniel → dunham]

macOS has a formal sandboxing language; I first learned about it via iTerm2's build process: https://gitlab.com/gnachman/iterm2/-/blob/v3.5.12beta2/deps.... consumed by /usr/bin/sandbox-exec https://gitlab.com/gnachman/iterm2/-/blob/v3.5.12beta2/Makef...

I haven't tried to use it in anger, but I believe this is the likely starting point https://developer.apple.com/documentation/xcode/configuring-...

[dunham → mdaniel]

I've attempted to use the sandbox-exec utility, but didn't have the stamina to get a working sandbox file written.

In general, I'd like to be able to sandbox more things. I'm using the app store version of slack because slack doesn't really need access to all of my files.

[retsl → dunham]

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.

[regularfry → retsl]

I think in context the challenge here is to use remote editing to treat the container as a VSCode remote. As shown, that's not enough of a sandbox because the agent gives a route out.

[raggi → dunham]

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