[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?