4 ms·

There is a Feature request from 2018 that I have been following for a long time to ask for VSCode Sadbox. I do not understand how Microsoft is not putting it up

by jakemm 5mo ago

There is a Feature request from 2018 that I have been following for a long time to ask for VSCode Sadbox. I do not understand how Microsoft is not putting it up in priority. https://github.com/microsoft/vscode/issues/52116 https://github.com/microsoft/vscode/issues/52116

xeyownt 5mo ago
"VSCode Sadbox" -- pun intended or not, that's funny :-)
panzi 5mo ago
On one hand yes, sandbox everything. On the other the extensions still can change your code which you then run. Though you might only run it in a container at first. I heared zed sandboxes extensions. I should have a look at that editor some day.
- HighGoldstein 5mo ago
  Sandboxing doesn't necessarily mean isolating the extension from all potentially dangerous functions, you can have a permission system so that for example a color theme extension can't modify files.
- insanitybit 5mo ago
  Not every extension needs the ability to change your code, let alone change it without user interaction - similar to how iframe sandboxing can allow top level page navigations with user consent. Also, modifying my code is far better than just launching, stealing everything silently, and having full control over my system. Needing to inject some sort of malware into an arbitrary project is way better.
gchamonlive 5mo ago
Sandbox alone isn't sufficient because when loading a malicious extension into a session you might be exposing your environment variables to it. You also need explicit permissions, so that only relevant extensions can access secrets like this. And even if this exists, and you are sandboxed, with all guardrails and such, if you trust an extension that later gets compromised, you'd get the same sadness. It's the problems with trusting trust all over again... Maybe sandboxing, plus freezing updates for at least a week, then on each update reviewing the permissions for each extension, then reviewing the extension itself for compromises. Something that should be done not by the user but by the supply chain itself.
- insanitybit 5mo ago
  Sufficient for what? It's sufficient for preventing an extension from accessing tokens on my filesystem, from connecting to arbitrary networks, stealing my browser session cookies, etc. It's sufficient for a fucking lot. This is how browsers have been doing things for 20 years, it's ridiculous that a company worth billions isn't doing it.
  - gchamonlive 5mo ago
    Don't know what you are talking about, browser extensions implement granular permissions on top of sandboxing too. https://developer.chrome.com/docs/extensions/reference/permissions-list https://developer.chrome.com/docs/extensions/reference/permi... https://support.mozilla.org/en-US/kb/manage-optional-permissions-extensions https://support.mozilla.org/en-US/kb/manage-optional-permiss...
    - insanitybit 5mo ago
      Perhaps I was unclear. I am suggesting exactly that browsers do this correctly and that vscode should be following that old, tried and true model.
hahn-kev 4mo ago
Sadly the LSP pattern means that most extensions launch their own process so there's limited sandboxing options there. Sure not every extension needs its own process, but if most of them do then there's very limited benefit from permissions or sandboxing. As nice as the LSP is, the design basically means any IDE wanting to use common ones need to let extensions include and start their own processes.

by jakemm 5mo ago

xeyownt 5mo ago

"VSCode Sadbox" -- pun intended or not, that's funny :-)

panzi 5mo ago

On one hand yes, sandbox everything. On the other the extensions still can change your code which you then run. Though you might only run it in a container at first. I heared zed sandboxes extensions. I should have a look at that editor some day.

HighGoldstein 5mo ago
Sandboxing doesn't necessarily mean isolating the extension from all potentially dangerous functions, you can have a permission system so that for example a color theme extension can't modify files.
insanitybit 5mo ago
Not every extension needs the ability to change your code, let alone change it without user interaction - similar to how iframe sandboxing can allow top level page navigations with user consent. Also, modifying my code is far better than just launching, stealing everything silently, and having full control over my system. Needing to inject some sort of malware into an arbitrary project is way better.

gchamonlive 5mo ago

Sandbox alone isn't sufficient because when loading a malicious extension into a session you might be exposing your environment variables to it. You also need explicit permissions, so that only relevant extensions can access secrets like this. And even if this exists, and you are sandboxed, with all guardrails and such, if you trust an extension that later gets compromised, you'd get the same sadness. It's the problems with trusting trust all over again... Maybe sandboxing, plus freezing updates for at least a week, then on each update reviewing the permissions for each extension, then reviewing the extension itself for compromises. Something that should be done not by the user but by the supply chain itself.

insanitybit 5mo ago
Sufficient for what? It's sufficient for preventing an extension from accessing tokens on my filesystem, from connecting to arbitrary networks, stealing my browser session cookies, etc. It's sufficient for a fucking lot. This is how browsers have been doing things for 20 years, it's ridiculous that a company worth billions isn't doing it.
- gchamonlive 5mo ago
  Don't know what you are talking about, browser extensions implement granular permissions on top of sandboxing too. https://developer.chrome.com/docs/extensions/reference/permissions-list https://developer.chrome.com/docs/extensions/reference/permi... https://support.mozilla.org/en-US/kb/manage-optional-permissions-extensions https://support.mozilla.org/en-US/kb/manage-optional-permiss...
  - insanitybit 5mo ago
    Perhaps I was unclear. I am suggesting exactly that browsers do this correctly and that vscode should be following that old, tried and true model.

hahn-kev 4mo ago

Sadly the LSP pattern means that most extensions launch their own process so there's limited sandboxing options there. Sure not every extension needs its own process, but if most of them do then there's very limited benefit from permissions or sandboxing. As nice as the LSP is, the design basically means any IDE wanting to use common ones need to let extensions include and start their own processes.