[Gigachad]

The problem extends far beyond VS code. All extensions and executable code has the same problem. There was a case where Disney was hacked because an employee installed a BeamNG mod that had bundled malware.

A company that wants to remain secure would have to employ strict restrictions on installing software. Only installing npm packages and plugins from an internal preapproved repo for example.

[miki123211]

Running code isn't the problem. The fact that (almost) all code runs at the same security level is.

You regularly run tons of untrusted code when visiting websites. That code can't wreak havoc on your machine because it's well-sandboxed. Yet, if we advocate for sandboxing in more places, the "gun nuts of tech" scream about monopolistic practices and taking away user control.

[atq2119]

Fully agree with the first half of your comment. The second half goes off the rails, though.

I rarely see people complain about sandboxing.

What people complain about is when devices are locked down in a way where you are only allowed to install software that is approved by a central gatekeeper, even though sandboxing is in place that should make it far safer to run arbitrary safer than on traditional desktop systems.

[nstart]

Agreed. What's frustrating is that we have models for how sandboxing can work and instead of investing efforts into nailing that experience, the OS providers are prone to turning it into a monetization/lock in layer instead. My VLC and VS Code should have an OS native way of being limited to particular functionality. But when the OS providers implement the sandbox, they center it around an App Store and restrictions on only apps that have been notarized where said notorization costs money or a requires a subscription. And then they remove the ability to do things which their own native apps can do and set tighter controlling rules on what APIs apps can ever have access to.

When all I wanted was for VLC or similar to run in a sandbox by default where a plug-in I install can't do anything to my system or access the internet by default because the software itself is restricted to just the files I'm using and that's it.

[Gigachad]

That exists on linux under flatpak, but it requires Wayland and Pipewire. Also many packages just request full system permissions rather than update to work in a sandbox.

It's in the works and one day we will have it but progress is slow.

[skydhash]

I really like openbsd's pledge. It's nice when you look at the code and see the program restrict itself to a smaller set of operations. Not everything in ports has adopted it, and the point is moot for closed source. But for the latter, VM and an isolated segment would be the proper solutions.

[mschuster91]

> My VLC and VS Code should have an OS native way of being limited to particular functionality.

The problem is... it's hard to scope. A media suite such as VLC, simply by what it is intended to do, needs a lot of permissions. Read data from physical media drives (CD/DVD/BD), preferably directly against the device to circumvent DRM. Access the network 0.0.0.0/0 1-65536 TCP and UDP to be able to play all sorts of streaming media. Access all files the user has access to on the computer because everything can be a media file and no operating system available does MIME type detection. Write to files on the user's computer to do stuff like format conversions and screen recordings. Access the screen framebuffer and the user's microphone for said screen recordings. Open network listen sockets to be a streaming endpoint.

Unless filesystems get a distinct metadata field to each file, there really is no viable way to sandbox it.

[skydhash]

A viable strategy is something like qubeos for isolating activities from each other. You can have a media vm, a dev vm, a bank vm, and a password/manager vm. Or you use different computers.

I think one issues has been having code hosting/build systems/deployment pipelines under one ecosystem with non scoped keys. Especially your deployment keys should be on a service that only interacts with inert archive (no building or downloading anything).

[dingdongditchme]

As a "gun nut of tech", I have resolved this issue for myself with two computing categories for hardware I use: Hardware-I-trust and Hardware-someone-else-trusts. Sometimes these share information, and have to interact. Usually I am the one who decides how. Smartphones have never been in the category of "Hardware-I-Trust". For the first time in a long while my current employer paid for hardware is in that category for reasons of my own.

[swiftcoder]

> Yet, if we advocate for sandboxing in more places

Sandboxing plugins is pretty much universally desired? You seem to be conflating this with the issue of platform gatekeepers deciding which software is allowed to run on our own hardware

[salawat]

Never let a crisis go to waste, huh?

We've had the solution to shit like this, and it's called the SecurityManager in Java. No one wants to configure the damn thing, but it is there. Also, auditing the code you pull in. Yeah. Reading code sucks. Yeah. It's a lotta work. But if you don't check, you don't effing know.

All y'all want the fun of unprotected sex (rawdogging the ecosystem) and are starting to get burned by the VD's we old-timers have been hollerin' at you telling you will be coming the more you do this promiscuous dependency inclusion.

But hey. Enjoy it I guess. No skin off my nose.

[hnlmorg]

> Also, auditing the code you pull in. Yeah. Reading code sucks. Yeah. It's a lotta work. But if you don't check, you don't effing know.

While I do generally agree with this sentiment, it’s not always possible in the ways you imply:

- Plenty of systems pull packages that are not human readable. For example WASM plugins. Or it might even by in unfamiliar languages such as a Python package calling C.

- You might argue that “if you cannot understand the code then don’t use the package” but that isn’t always practical. Security packages will include maths that is beyond the average software engineer. Other performance-critical packages (such as libraries in the ML space) will have highly optimised code that isn’t easy for the average developer to read through.

- Some supply chain attacks have been targeting popular packages. So now you need to re-read every single point version (!!!) on every update. Heck, even using lock files to the patch version in semver might not save you for some language ecosystems because you can overwrite git tags. So a package version that is safe on your local machine might end up compromised when compiled via CI/CD.

- And then there’s CI/CD itself. We are seeing supply chain attacks in GitHub Actions plugins. So now you have to pin all of your actions to their SHA instead of semver.

There definitely needs to be a better security model to support developers because the current status quo makes it very hard to vet everything you run, and very easy to fuck up. In all other fields of IT, we’d say that was a failure of the process rather than a failure of the individual.

[galkk]

No, it doesn't have Security manager https://docs.oracle.com/en/java/javase/17/docs/api/java.base...

and the fact that you mention it means that you haven't used it too, because the tools are screaming in logs that it is deprecated.

[Gigachad]

This is about as useful as telling people to read the full terms of services of everything they use. That might be easier than auditing every line of code you run.

I’ll tell my employer to put the feature on hold for 20 years while I read the source of every package.

[raxxorraxor]

Yes, because sandboxing gets us unusable OS like iOS or Android. It isn't a solution. Perhaps the gun nuts are right then. Better be a gun nut than a Google employee, probably.

[antiframe]

In what way is Android unusable?

[xyzzy123]

Funnily enough a lot of this "extension sprawl" is caused by the _difficulty_ of installing tools on locked down Windows machines. I recently moved to a locked down SoE and instead of being able to use regular tools (which require a lengthy negotiation process to install) I now use extensions for absolutely everything, _because_ they're not currently policed in the same way...

[ihateolives]

At my last workplace I was not allowed to install JSON viewer/prettier extension for my browser, but I was allowed to install VScode with random JSON plugins.

[3form]

I see the same thing. Similar for PyPI and NPM registry actually.

[charlieyu1]

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.

[inlined]

What are you withholding from the sandbox without making it useless?

[atq2119]

Internet access. An editor extension does not need it.

[larusso]

Most sandbox systems today, take seatbelt from Apple for instance, only strip permissions. If your extensions without internet access calls a tool that needs it, boom access denied or worse, weird network issues.

One would need some kind of ring system where less privileged processes can call higher privileged processes with their own sandbox permissions.

[atq2119]

Sure, that's the main challenge with building good sandboxing systems. But it's not actually that hard to do when the will to do it is there.

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.

[therealdrag0]

Let the user grant permissions at install time. An error is a success in this scenario.

[sedatk]

All AI agent extensions disagree in unison.

[californical]

It could request access to a specific domain which you can approve or deny

[Gigachad]

Because it's hard to create a system that is both sandboxed and powerful. You can't have an extension system that allows a plugin to run a locally installed linter or view the status of docker containers but can't execute something malicious.

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.

[moring]

> You can't have an extension system that (...)

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

[vlovich123]

I don’t know what linters you use, but the ones I like are the ones that show you problems in the workspace stably, not just in the files that happen to be open and altering as files open and close.

You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.

[moring]

This was bad wording on my part. I wrote "open" but that should have been "files in the workspace/project". Really, "open" WRT files is so overloaded already, they can be in the workspace, have an editor tab open for them, or have an active file handle, to name just three.

> 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.

[vlovich123]

Im highlighting that defining that sandbox policy cohesively in a way that works for all the different extensions types you’d want to support and doesn’t overwhelm the user with permission fatigue is difficult as to be impossible.

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.

[Gigachad]

These kinds of permissions lists have been mostly a failure in history. Users see a massive list of permissions, or permissions constantly changing between updates and just ignore them because there’s no way to reasonably audit them or take any action on them.

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.

[moring]

Ideally, the permission list is meant for curators which end-users trust and can rely on.

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.

[Gigachad]

Most of the recent compromises have been from trusted people who had their accounts compromised. So just picking someone you trust doesn’t work out.

[charlieyu1]

I don’t know, we got rid of things like CGI and Java Applets for web but things are still useful enough

[yard2010]

The shit show that's called lastpass, which I unfortunately know, was hacked because a developer installed a bad version of Plex Media Server on his work computer.