Who does this benefit? I can think of two groups of people. 1. Commercial software vendors who want more Linux users to install their proprietary software. 2. 'Transplants', new Linux users who are already accustomed to the Windows/MacOS style of wantonly installing proprietary third party software they downloaded off random corners of the net, and don't want or know to change their habits.

The value proposition for experienced linux users who don't do that sort of thing in the first place is next to nil. The only applications that might benefit from such sandboxing are applications like browsers, which have large attack surfaces and might be compromised while browsing the net. But even this is mostly theoretical, not a realistic day-to-day concern for typical linux desktop users.

You are jumping to conclusions here. RCEs are probably more common than you think, and I'd prefer anything that interacts with the Internet to be sandboxed.

Flatpak allows me to easily sandbox Steam games. It provides an easy target to tell user to test against to eliminate distro-specific issues. It allows to run glibc-only software on distributions such as Alpine. It allows me to have multiple versions of a program installed concurrently. It prevents programs from cluttering my home directory, and sandboxing gives me extra peace of mind. As a non-root user, I can also install flatpaks. Ostree also usually makes updates more efficient.

If you use a couple flatpak apps, they are available regardless of your distribution. That helps when working on multiple different distributions.

Use an old-ish debian but need a feature from the latest unstable software ABC? Install ABC as a flatpak, and do not compromise the stability of the base system by enabling all sorts of external, unstable sources.

If you can run the "beep" command, you can also edit the user's environment and from their easily escalate to root anyway. In modern desktop linux, the user is almost always the admin as well, a single person using their personal computer, so getting root is merely a matter of waiting until the next time that user uses sudo/etc. Windows tries to mitigate this sort of attack using secure UAC prompts that are apparently difficult for attackers to emulate, or so I've been lead to believe. But common desktop Linux distros don't require anything like that. Instead, the user has to be cognizant of such possibilities and not run programs from people and organizations they don't trust.

There’s also systems like Arch’s AUR which is quite popular and more likely (if still unlikely) to carry malware, to the point that the Arch Wiki warns that use of AUR is at the user’s own risk.

Plus, many people are going to need to use proprietary software, which is always an unknown and likely to act badly in any number of ways. A lot of such software is Electron-based to boot, and devs are notorious for using ancient (and vulnerable) Electron versions.

Do use Linux on the desktop and be happy if it makes you happy, but don’t smugly assume you’re immune to the outside pressures in today’s world that are causing Apple to institute basic UI security measures on macOS. This isn’t a walled garden issue, it’s “make sure the user knows this binary is doing something that allows it to be a keylogger if the developer is so inclined.”

Some distros like RHEL already bundle apps with profiles that make sure the app can only do what it's supposed to do.

Also it is totally not fit for the "ask user for permission" model.

Like, stock RedHat does too, it just took a ton of effort (and bugs) to get there.

But then it is complex problem so its no wonder that the tools to do it are complex too

I wouldn't actually mind android-like permission model for out-of-distro packages (snap/appimage/etc.), maybe a bit expanded so I could say set this this and that folder for the "graphics editng app", and maybe save that as a profile to apply to some other similar app to ease on repetition/alert fatigue.

With maybe a layer to abstract some operations to not be just "allow this(remember choice)". Like file opening, if app calls to open a file I "just" want DM/WM specific open dialogue, with app/container name in the title and select the file to open.

Same for editing, I'd want to be able to just get dialogue "open file for editing", with app name and the permission to edit said file saved for the duration of the session so app doesn't need to re-ask me every time it saves the file.

why would you? that's the package maintainers job. each of these dependency also has a maintainer, so by definition all dependencies have a provenance that is as good as the package you are installing.

this is not npm where anyone can upload something and you have to check the provenance of each yourself

Sure, it's better than closed source, because at least you have the possibility to check all this. In practice though, we outsource this responsibility to the package maintainer of the package system we use.

not true, for years there are efforts in various distributions to make package builds reproducible. there are ways to build a package from source that allows you to get the same results and verify it.

we outsource this responsibility to the package maintainer

which is the point. i trust the package maintainers to do a better job at that than myself.

People often just drop the word “sandbox” and say “applications are sandboxed” and that that means that they're safe but it's really not that simple in practice. What often happens is that such applications still need to communicate over some socket with some server that was never designed for such a sandbox, say PulseAudio, and in many cases can then simply instruct the outer daemon to do whatever they want with full permission, either by design, or by oversight since the no one who wrote the outer daemon thought about it at the time since they were never designed for that purpose.

This is why there's a push to do as much as feasibly possible in userland in both macOS and Linux, so even when a bad actor tries to route through system components the blast radius is limited. Realistically, they should be sandboxed too — an audio daemon for instance has no business directly accessing storage or network facilities for example.

What I'm about to say may seem wrong, stupid, or crazy at first. I think permissions often belong in the GUI. Applications would get no access to the file system directly, but they could use an API in the gui to open files - only files that are granted access by the user, often by selection in a File->Open dialog or other direct user interaction. By putting the granting of access in the GUI toolkit, we can run untrusted apps natively with no OS permissions.

Maybe not directly in the GUI, but something like that. Trust the user but not the app.

To the extent that it is the OS's job, you don't have a computer anymore. You have an appliance. Sometimes that's OK; I don't complain because I can't run Doom on my dishwasher. But let's be clear about what is a general-purpose personal computer, and what is not.

In my opinion, that depends on the existence of an escape hatch. If it's like iOS where there effectively is none, sure, but if it's like macOS where SIP, Gatekeeper, etc can be temporarily disabled to make changes and then re-enabled or disabled entirely it's a different story.

Last year you might have heard a court case talking about a nurse who killed a woman by accidentally giving her the wrong medication. She took responsibility but talked at length about how the system in place encourages workers to blindly click yes on alerts about medication because there are many of them. The training they got was basically “just click yes three* times” (* I don’t remember the actual number but three seems right).

One of those warnings could have saved a life had she read it, but she had been clicking yes many times a day every day for a long time and she no longer even saw the banner for what it was.

Interesting stuff from a UI/UX perspective.

Regardless, I'd still like the final say in making that decision, otherwise it's not really my computer anymore, is it.

If a systemwide "disable all safeguards, give all programs access to everything all the time" switch exists, the level of friction encountered when accessing it should be very high to help deter social engineering attacks. It's a one-time action so the annoyance level of that friction is negligible, since those using it will only need to do so on clean installs.