It is, but my argument is that better security is not needed! There is only one user. All apps are his/hers.
Linux security inside a user's session is bad in general. It all started in the '90s from the principle that all installed software is FOSS, sources inspected, and compiled distro packages trusted.
- Permissions are per-user, not per-app. If I ever need permissions to something, every app I run gets the same permissions.
- No isolation for personal files. Any app running as me can read all of them. Bookmarks, firefox passwords, everything.
- No per-app firewall mechanisms. Any app can call home and send user's files, including those passwords.
- System events are broadcasted via dbus to any app wanting to listen to them.
So why make the GUI secure if everything else isn't? If anyone wants to have better security (or privacy) in Linux, would have to start with the basic permissions model.
More importantly, adding more security has a real cost because either you just can't do some things or need to punch a bunch of custom-built holes in your security. If you can avoid paying that cost by having only trusted software why wouldn't you.
It’s not about multi-user security. I would not like a compromised video player to be able to see my Signal chats just because both apps are in the same window system.
Does Signal save history? Or does it save your encryption keys in a file? If it does, then a compromized program can just read those files directly. No need for X, no need for a GUI, a simple console app can do it.
More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory, etc. and impersonate you. Also without X.
> Does Signal save history? Or does it save your encryption keys in a file?
Even on Signal Desktop, retrieving things from an outside app is very-hard-to-impossible depending on configuration and what you're after.
There's a reason most Signal bots (even benign ones) hook up an event stream to a specially configured Signal daemon and build an external record of data from Signal by watching for events over time.
> More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory...
I think you're missing a lot of the attack surface here. "Local execution is game over" is a technically-true-but-incomplete thought-terminating statement; it's more useful to assess "if I grant local execution, what attackers are likely to be interested in that, and what attacks are they likely to perform?"
Like sure, if you install something containing a full userland rootkit designed to attack a given application, and that application isn't running in a container such that you have to pivot through root to access it, you're screwed.
Those do exist, but there are a ton of local attack vectors that aren't that. Many pieces of malicious code that install with local apps aren't that complex, since complexity begets size and suspicious-behavior detection. Less complex malware would prefer to e.g. read Firefox's sqlite database files rather than try to execute new instances of trusted programs like Signal to get data out of them. We know from analysis of a lot of malware that it overwhelmingly prefers low-hanging fruit that's easy to harvest quickly and without doing much that risks detection. Some malware's scarier, but like Mickens said, most people a) aren't gonna get Mossad'd on, and b) can't do much about it if they are: https://www.usenix.org/system/files/1401_08-12_mickens.pdf
There are also local attack vectors that don't involve installing malware directly. Local programs that run code (browsers) and plenty of other exploits in e.g. decoders are limited enough in what's possible within the exploit chain that they can't calc.exe you and instead rely on info harvesting from speculative execution
Flatpak/Snap/etc., also can assist with a layer of local-app security here.
Put all that together, and you end up at the conclusion that a large volume of data is only practically accessible to a lot of malware by accessing another running app's memory. Two significant ways to do that are 1) reading memory directly (significantly mitigated by hardware permissioning/segmentation/ASLR) and 2) reading data those apps publish to the display system. Wayland makes that second one a lot harder.
Linux security inside a user's session is bad in general. It all started in the '90s from the principle that all installed software is FOSS, sources inspected, and compiled distro packages trusted.
So why make the GUI secure if everything else isn't? If anyone wants to have better security (or privacy) in Linux, would have to start with the basic permissions model.