3 ms·
Instead of working with existing remote tools it deploys a comprehensive agent that includes: A Node.js binary installation. A WebSocket connection back to the
by andrewfromx 2y ago
Instead of working with existing remote tools it deploys a comprehensive agent that includes:
A Node.js binary installation. A WebSocket connection back to the VSCode frontend. Extensive system access capabilities.
The VSCode agent has broad permissions including:
File system navigation. File editing capabilities. Shell PTY process creation. Self-persistence abilities.
- jazzyjackson 2y agoIt’s not clear to me, are these issues on the local or remote vs code instance? If remote, I understand elisp tramp is a lighter touch as far as dependencies go, but is the attack surface all that different? (That is, does the remote node binary have any permissions a user running arbitrary ssh clans wouldn’t?) The OPs goal was to give an llm keys the kingdom on an ephemeral/throwaway virtual machine, are they saying the sockets opened up by the agent allow it to fiddle with the developer machine it’s meant to be isolated from?
- throwanem 2y agoEmacs Tramp just uses whatever SSH access you already have to a remote host, to copy files back and forth. It may use scp or sftp if the remote host advertises the protocol, but it does not install anything or invent any of its own protocols.
- regularfry 2y agoNow I'm wondering if you could inject an emacs lisp interpreter onto the remote machine. There are exploit frameworks that do something similar. Whether such a thing should ever be written is a completely different question, of course.
- kreyenborgi 2y agotramp doesn't require running anything on the remote server, it's more like using sshfs. But if you find an exploit that will run by simply editing a file in emacs, you could put that file on the server and
- regularfry 2y agoYeah, I know. I'm not talking about tramp. What I'm saying is that you could do precisely the same thing vscode does, probably without adding any new code to emacs, as long as the client and server architectures matched. The client would just send its own elisp interpreter across the wire and run it, giving itself a remote repl you could have it run anything in. That would, of course, be just as terrible an idea as when vscode does it.
- AlotOfReading 2y agoI don't see any reasonable alternatives that can support what VScode does, like running extensions that aren't installed locally. Maybe those features aren't something you want, but they're part of the product feature set.
- roland35 2y agoI believe extensions are actually installed on the host itself! At least when I use vs code remotely it shows "install on xxx" for each extension if I haven't installed it yet
- knallfrosch 2y agoExactly. You can use extensions without even installing them locally. They're installed on the host. Now imagine your host is a rented VM that you throw away after use.
- dekhn 2y agoOne perspective is to think of these as things that a modern OS should provide as a standardized feature, and VSCode is just working around the fact they don't exist. It's crazy to think about but the kernel itself could have a webserver (or other protocol) with encryption and auth that let you directly control the entire machine through EBPF. It could be an entirely different paradigm for client/server remoting. Also a security hole you could drive a death star through.
- eru 2y agoYou can have a standardised feature set, without sticking everything into the kernel. I'm all for the former, but the latter is unnecessary.
- otabdeveloper4 2y agoA rootkit built right into the kernel? And apparently this is okay because it's "encrypted"? (Aka impossible to diagnose or monitor.) Yikes.