Insecurity through obscurity is possible even in open source. See log4j, but there are other examples — and infinite proof of concepts of people breaching repositories. Even on the desktop, you want multiple layers of security to limit potential damage.
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.”
Android app vendors are not writing their own policies. So there is a lot of code between SELinux and "what's actually usable to the user".
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.
Indeed. The idea of flatpack is to change desktop linux culture by normalizing the installation of 3rd party software, particularly proprietary software that people otherwise wouldn't trust without some form of sandboxing.
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.
> 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.
In those 6 years, how many programs packaged and distributed by Debian were exploiting that?
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.
Yeah, because I definitely double check the provenance of the 30 dependencies that blow past my terminal when I apt install something, that I also very much looked into and aren’t blindly typing commands from Stack Overflow into my terminal because I’m trying to solve some problem.
because I definitely double check the provenance of the 30 dependencies that blow past my terminal when I apt install something
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
Repos are generally safer yes, but they can still act as vectors for malware.
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.
every package system (apt/yum/pkg/whatever) is distributing binaries.
So yeah, the upstream project can be open source, but there is 0 guarantees that the binary I install on my system is the exact same binary as I would get if I build the source myself (and this does not even touch on the subject that compilers can add weird stuff as well)
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.
there is 0 guarantees that the binary I install on my system is the exact same binary as I would get if I build the source myself
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.
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.”