Media decoders are an important attack vector. Examples include PDF viewers and the library that produces thumbnails for display by the file browser. (One way to attack a media decoder is to get the user to open a malicious email, but there are other ways.)
The web browser is an important attack vector, and there are no Linux distros that sandboxes the browser anywhere near as effectively as Android and ChromeOS do except maybe Qubes, but Qubes is stuck using X for the display server and using Zen, both of which have been abandoned by their maintainers and aren't receiving enough maintenance attention to fix security vulnerabilities. I.e., Qubes's reputation for security probably comes from the fact that it was relatively secure many years ago.
Android and ChromeOS use selinux to sandbox the browser. Fedora uses selinux, too, but it only sandboxes server software: any program including a web browser started by the user is unconstrained (unaffected) by Fedora's selinux implementation.
The kernel is another important attack vector (and Linus has always been bored by and impatient with security considerations.)
Ditto the C library. Note that GrapheneOS uses a special, hardened C libary (which in the last few years has migrated to at least one security-focused Linux distro, namely, secureblue, but of course none of the people that show up here on HN proudly proclaiming that Linux is more secure than iOS or Android use secureblue, and the lead of the secureblue project freely admits that MacOS iOS Android and ChromeOS are more secure than secureblue is).
You know how one of the arguments for Wayland is the fact that there is no way to prevent any process from reading the contents of any X window? Well, to actually achieve this "window privacy" inherent in Wayland requires active support from the compositor, and Gnome has the only Wayland compositor that actually provides this support.
Till the vulnerability started getting exploited some time last year, anyone could upload a theme to KDE's theme store that could run arbitrary code when the user chose to install it. No one was reviewing uploaded themes for malware or warning users of the danger.
Hyprland uses a trampoline (files at a known location in the file system that are occasionally executed by Hyprland) for reasons that are hard to explain if we assume that Hyprland's maintainers care anything about security.
Of course the browser still is an attack vector but the relevancy of that vector is lower today. Same goes for these examples. These are exploits and they will always exist, sandbox or not. A few years ago you could log in to MacOS as root without a password. Meta just released a memo two days ago that Whatsapp exploits compromised Android and iOS devices. Guess it was sandboxed, but all users allowed the app to access files and contacts anyway.
Today the main problem is social engineering and scams. The disadvantage of mobile OS are too great to justify bad approaches to desktop systems or security in general. And for browsers that means the security threat isn't some arcane media decoder, it is the well made phishing site.
But my argument is more that perhaps I don't want window privacy because it doesn't fit my security needs and reduces functionality and access. And one assumption in that is that one compromised app can compromise the whole system in the worst case and believe risks must be mitigated elsewhere. In case of doubt, I can reasonably sandbox something I execute myself, if the need is warranted.
I would love a good file explorer for my mobile device. But file access is restricted. How many hours wasted to bad security...
It's always entertaining to see security people struggling to understand what security is there for. They just consider "security" as the goal in itself, because being more secure is obviously good, right? Yo dawg, I've put a sandbox into your sandbox so you can be secure while you are secure.
If you insist that using software with trampolines means not "caring anything about security", I'm afraid it's a you problem. I'll still be happy to hug my partner when she comes home regardless of what germs might have been on a tram's seat she was sitting on on the way there, regardless of whether someone thinks that this means I don't care anything about health (I'm sure someone does).
In case someone needs it spelled out: I do care, but there are other things I care about too and I won't let some minuscule threats ruin them.
The threat model I think about a lot is supply chain attacks.
We’ve found out about a handful of such attacks over the last few years - like xz. And I’ve seen the number of random dependencies which get pulled in by most nodejs, cargo or python projects. The dependencies just scroll on by. There is no vetting process for putting code in npm or cargo. Nobody signs off on anything. Nobody reads the source code. There are no checks, and you can put anything in there.
If malicious code slipped in, would you even notice? I probably wouldn’t. How terrifying.
Linux’s security model means that any malicious code in a crate can run as me and access all of my files. Or delete them or whatever it wants to do. To me this is crazy. There’s no reason to give arbitrary untrusted code full permissions to all of my files and data - but there we have it.
I worry that it’s only a matter of time before we see more attacks like this. It’s such an obvious attack. And our lax endpoint security makes the vulnerability a way bigger problem than it needs to be. It would be trivial for a remote attacker to install C&C software on my computer. They could grab my SSH certificates and install backdoors in any of my projects on github. Read my email. Impersonate me. Crypto locker my stuff. Install malicious extensions into my web browser. And on and on.
None of this would be possible with proper isolation. There’s no reason a build.rs file needs write access to my whole filesystem. It’s crazy.
The web browser is an important attack vector, and there are no Linux distros that sandboxes the browser anywhere near as effectively as Android and ChromeOS do except maybe Qubes, but Qubes is stuck using X for the display server and using Zen, both of which have been abandoned by their maintainers and aren't receiving enough maintenance attention to fix security vulnerabilities. I.e., Qubes's reputation for security probably comes from the fact that it was relatively secure many years ago.
Android and ChromeOS use selinux to sandbox the browser. Fedora uses selinux, too, but it only sandboxes server software: any program including a web browser started by the user is unconstrained (unaffected) by Fedora's selinux implementation.
The kernel is another important attack vector (and Linus has always been bored by and impatient with security considerations.)
Ditto the C library. Note that GrapheneOS uses a special, hardened C libary (which in the last few years has migrated to at least one security-focused Linux distro, namely, secureblue, but of course none of the people that show up here on HN proudly proclaiming that Linux is more secure than iOS or Android use secureblue, and the lead of the secureblue project freely admits that MacOS iOS Android and ChromeOS are more secure than secureblue is).
You know how one of the arguments for Wayland is the fact that there is no way to prevent any process from reading the contents of any X window? Well, to actually achieve this "window privacy" inherent in Wayland requires active support from the compositor, and Gnome has the only Wayland compositor that actually provides this support.
Till the vulnerability started getting exploited some time last year, anyone could upload a theme to KDE's theme store that could run arbitrary code when the user chose to install it. No one was reviewing uploaded themes for malware or warning users of the danger.
Hyprland uses a trampoline (files at a known location in the file system that are occasionally executed by Hyprland) for reasons that are hard to explain if we assume that Hyprland's maintainers care anything about security.