I don’t understand why we don’t just sandbox everything. We have done it for web browsers, we can definitely do it for VSCode extensions.
One would need some kind of ring system where less privileged processes can call higher privileged processes with their own sandbox permissions.
For example, Android already allows you to give apps restricted access to your media. My understanding of the way it works is that the resulting interface for picking photos etc. is not under the control of the app. The app only receives whatever file you picked.
I do agree though that it is incredibly important to start taking sandboxing seriously. But there is a lot of difficulty and friction, and most of the users will scream and cry about extensions being limited.
Yes you can. Extension systems of today have multiple problems that prevent that. The basic assumption that has to go, though, is that a core application like VSCode can be written once, then be extended to infinity without the core evolving. That's an assumption you see everywhere in extension systems, and it restricts everything to "features or security, but not both".
Taking your examples:
> run a locally installed linter
VSCode and its extensions have certain files opened. The linter can do much less if it gets read-only access to those files, but not write access and no other files, not the open internet or something.
This has then to be coupled with those permissions being displayed before installing, allowing them to be reviewed by users as well as plugin repo curators. Basically listing those permissions as declarative metadata.
Because then a user or curator won't see "this plugin can read and write all your files" but "this plugin can read (but not write) the files being opened by VSCode". If the plugin wants to exfiltrate those files, the permissions would also list "this plugin can send HTTP requests to totally-legit-site.ru" instead of "this plugin gets arbitrary internet access".
Main lession: permissions are WAY too coarse. But if they are fine-grained, they will soon no longer match the evolution of extensions, so the core system has to evolve too.
> view the status of docker containers
"This plugin can view the status of all docker containers started by other VSCode extensions in the same VSCode window".
> users will scream and cry about extensions being limited
Are those the same users? We might need two different products here, "feature VSCode" and "secure VSCode".
You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.
> You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.
I claimed that it is possible, not that it is easy.
Browsers have a different problem - they protect different websites against each other. The IDE should probably protect you against extensions being able to access arbitrary files on disk, but even that’s difficult (eg a bundled linter often wants to read user defaults in a central location. But protecting even further than that is even harder, especially as here where the access was to the actual repo not anything else.
Securing VS code would require making malware that has access to the system impossible, not just making it add a permission to the permission list.
Also, historically, permission lists have been fine-grained but too coarse at the same time, meaning they were "fine" in the wrong way, based on what is easy to implement instead of what the user needs.