3 ms·

It's no different or worse than the security model of any other text editor or IDE. It runs as your user (unless you're doing something zany like running an ad

It's no different or worse than the security model of any other text editor or IDE. It runs as your user (unless you're doing something zany like running an admin account), and it can do anything your user can do like launch programs or subprocesses you have access to execute. A vs code extension isn't going to get some unexpected power like root privilege to start messing with your system, opening low ports, etc.

krono 4y ago
You're right, what I'm curious about is how difficult it'd be to sneak a malicious command into some VSCode extension update trough these production dependencies, and how far, say, an rm -rf <allthethings> could reach from the trusted project root directory from which it is executed. I'm not a VSCode user myself, but it's pretty much the same story with nvim. edit: I suppose what I'm really getting at, is that, depending on what their security measures look like, the VSCode extension store might be giving some false sense of security.
- lstamour 4y ago
  A lot of supply chain security relies on trusted actors doing the right thing. It’s similar to how you can trust an ingredients label. I suppose I could mention that on a Mac, I use Objective-See’s tools to watch what programs do in the background. And also on a Mac, you have to grant access to apps first otherwise they can’t normally access files. Of course, that breaks down in reality as most apps are useless if they can’t access files. If you really want a scare, consider that if you compromise an ecosystem package (e.g. npm), you can run on developer machines, CI systems and possibly in production, while if you compromise a VS Code extension, you only get dev machines. If you’re looking for a bit of extra protection, you can run VS Code from a virtual machine or even run it from Docker. Though the usual docker approach, using remote containers extension, still runs on your local computer. There’s GitHub Codespaces or Google Cloud Shell that can run VS Code remotely in a VM, though.
  - krono 4y ago
    Most projects I'm involved with require measures that go a bit further still. Got to be honest though, it can be frustrating at times. Just sprinkling bits of awareness around by bringing some of these considerations up whenever I can. It's an uphill battle, although, the general carelessness around extension and dependency use I'm seeing - and that even after all the shit that's been going on in that space - makes it one worth to fight. Edit: Regarding the chain of trust you mention, that one has sort of come and gone, and there is not a whole lot of trust involved in the processes I'm saddled up with.
SAI_Peregrinus 4y ago
That's an aspect from mobile OSes I miss on desktops: apps run as their own user, and have to be granted permissions to do things like read & write files outside their own "home" directory. Programs should run as their own users. Programs should be granted access to files opened via system (desktop environment) file picker APIs or when passed in via a shell. Desktop environments & shells would need to be modified to allow this, of course.
- wvenable 4y ago
  Mobile OS permissions are way too limited. It's one of the reasons there are no good programming environments on mobile. > Programs should be granted access to files opened via system (desktop environment) file picker APIs or when passed in via a shell. For example, this would render the file tree of any IDE or advanced editor (like VS code) completely useless. I can count on one hand the number of times I've used the system file picker when programming.
  - SAI_Peregrinus 4y ago
    It should also be possible to manually grant broader permissions. I'm just hoping to avoid how automatic grants tend to be missing from mobile OSes.

krono 4y ago

You're right, what I'm curious about is how difficult it'd be to sneak a malicious command into some VSCode extension update trough these production dependencies, and how far, say, an rm -rf <allthethings> could reach from the trusted project root directory from which it is executed. I'm not a VSCode user myself, but it's pretty much the same story with nvim. edit: I suppose what I'm really getting at, is that, depending on what their security measures look like, the VSCode extension store might be giving some false sense of security.

lstamour 4y ago
A lot of supply chain security relies on trusted actors doing the right thing. It’s similar to how you can trust an ingredients label. I suppose I could mention that on a Mac, I use Objective-See’s tools to watch what programs do in the background. And also on a Mac, you have to grant access to apps first otherwise they can’t normally access files. Of course, that breaks down in reality as most apps are useless if they can’t access files. If you really want a scare, consider that if you compromise an ecosystem package (e.g. npm), you can run on developer machines, CI systems and possibly in production, while if you compromise a VS Code extension, you only get dev machines. If you’re looking for a bit of extra protection, you can run VS Code from a virtual machine or even run it from Docker. Though the usual docker approach, using remote containers extension, still runs on your local computer. There’s GitHub Codespaces or Google Cloud Shell that can run VS Code remotely in a VM, though.
- krono 4y ago
  Most projects I'm involved with require measures that go a bit further still. Got to be honest though, it can be frustrating at times. Just sprinkling bits of awareness around by bringing some of these considerations up whenever I can. It's an uphill battle, although, the general carelessness around extension and dependency use I'm seeing - and that even after all the shit that's been going on in that space - makes it one worth to fight. Edit: Regarding the chain of trust you mention, that one has sort of come and gone, and there is not a whole lot of trust involved in the processes I'm saddled up with.

SAI_Peregrinus 4y ago

That's an aspect from mobile OSes I miss on desktops: apps run as their own user, and have to be granted permissions to do things like read & write files outside their own "home" directory. Programs should run as their own users. Programs should be granted access to files opened via system (desktop environment) file picker APIs or when passed in via a shell. Desktop environments & shells would need to be modified to allow this, of course.

wvenable 4y ago
Mobile OS permissions are way too limited. It's one of the reasons there are no good programming environments on mobile. > Programs should be granted access to files opened via system (desktop environment) file picker APIs or when passed in via a shell. For example, this would render the file tree of any IDE or advanced editor (like VS code) completely useless. I can count on one hand the number of times I've used the system file picker when programming.
- SAI_Peregrinus 4y ago
  It should also be possible to manually grant broader permissions. I'm just hoping to avoid how automatic grants tend to be missing from mobile OSes.