I do agree with that, and I strongly believe that the iOS and Android security model is way ahead of Desktop Linux. But what I observe is that nobody seems to care about the security model. A recurrent complaint I see against anything AOSP-based (including Android) is that people "want to be root".
But both Flatpak and Snap offer this new model from the two biggest desktop players in the Linux world: Red Hat and Canonical.
As the sibling comment said though, being an administrator for your own computer (including a phone) does not mean that you will be running untrusted applications as one: on the contrary, if you assume an administrator role and run an untrusted application, naturally, all bets are off. But even as a power user, I'd love to be able to safely run programs I do not necessarily trust, feeding it only data it needs and no more.
Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.
What most of these people do not seem to get is that proper sandboxing does not only protect against attacks from the inside (rogue developer, supply chain attack), but also from the outside. Most desktop apps probably have a good number of security vulnerabilities that can be exploited when they parse untrusted data. On the Linux desktop, most apps still use decades-old C libraries for parsing XML, images, JSON, etc.
Sandboxing also protects against external attacks.
Again, Snap/Flatpak provide this model, but we need to see more application authors take them up to ship their software.
Agreed, though for a lot of technical and social reasons, most apps still need privileges that allow trivial sandbox escapes on Flatpak (I don't know or care about Snap). Strengthening app sandboxing should be a top-priority for the Linux desktop, but only a few people seem to care. The same for fully verified boot, etc. Even things like UKIs only go so far, yet almost no distribution has adopted them.
The general security mindset of the Linux desktop community seems to be stuck in the 90ies, levitating between hahah, they cannot get root (as if that matters on desktop Linux) and secure boot and sandboxing is here to take my rights (on open source desktop Linux, seriously?).
Because, as I said in a sibling comment and cosmic_cheese notes further below, this requires rethinking the usage model altogether: files and folders, and even file types, don't work anymore.
If an app needs to access any related files, it basically needs access to my entire $HOME, and once that is granted, well, any sandboxing is out the window.
I think Linux community is well aware of that, and basically what we get from sandboxing of desktop apps is all the nuisance with no benefit.
Android model is also broken from a usage perspective: having files "owned" by an app is just as wrong, and precludes there being multiple apps operating on the same file. Example of VLC with subtitles is a common one, but if you've never used multiple apps on the same file, this is the challenge that is unsolved by any sandboxing approach today, because it is more of a UX problem, than a sandboxing technical problem.
All these things make security substantially better than the Linux model of every app gets access to your full home directory.
Sure, a capabilities-based OS or whatnot would work better, but would even be harder to implement in the current desktop Linux. Instead of gradually improving security, you are basically throwing away the baby with the bathwater.
But even with your example, you might need access to cover art from your graphics editing app, and very quickly you get to the same state. How about lyrics file from your text editor or a dedicated one? And wait, I'd like to mix in some music into Audacity too. File portals are actually a decent solution there, but they only work for files with supported software.
Yes, you can adapt your workflow, but it's going to be adapting and you will lose some things you might love in your workflow.
The problem is that strict file system sandboxing in particular also breaks a substantial number of workflows that can't be modelled as 'only ever open the exact file the user explicitly' picked. (Any multi-file file formats are particularly affected, as well as any UI workflows that don't integrate well with strictly having to use the OS file picker.)
So you need some escape hatch for optionally allowing access to larger swathes of the file system, or even really everything as before, but that in turn then risks being abused again by malicious actors. And then…?
Plus things like Android's implementation initially using an API completely incompatible with classical file APIs, as well as causing some noticeable performance overhead even today if you need more than simply accessing the occasional single file here and there.
For example, it’s useful for a music player with metadata editing features to have read/write access to the whole filesystem, but that constitutes a significant risk since all we can do is wholesale allow or prevent access to the whole filesystem. What if the system could allow it to access only music files, though? That’d scope the risk back down to almost nothing while also allowing the music player to do its job.
This is the kind of thing I’ve been getting at in the other replies. Nobody has really sat down and given system level security controls a deep rethink.
(Some sort of way to store permission references with relatives paths in a file, but which most probably wouldn't work with files being exchanged cross-platform, and other than that mainly being able to get automatic access to 'related' files, i.e. same file name, but a differing extension – that solves some sidecar files, like video subtitles, or certain kinds of georeferenced images, but large capability gaps still remain – even the video subtitle example stops working if the file name is no longer 100 % the same, like if you have multiple subtitle files for differing languages, where VLC for example supports prefix-matching the video file name with the subtitle files.)
And while your idea does have its merits, I fear that pretty soon you still hit a point where you can't sensibly and succinctly display those more complex types of permissions in the UI.
I could very well be wrong, but my inclination is that it's possible, but it's going to take the sort of fundamentals R&D that desktop operating systems haven't seen in decades. It can't just be tacked on, everything to be designed with this new system in mind.
On my Desktop I love Linux. But on my smartphone, I want AOSP.
But then on desktop/laptop-class hardware, since the thermal constraints are different and it’s nice to have extensible storage and RAM. Of course, all this on the phone is also nice for when you only have your phone with you.
Then one could use fully sandboxed apps for banks, instant messaging, etc. and the VM for development.
AOSP is getting pretty close to this ideal.
Yes I can totally imagine that in a few years, most people will only need a smartphone and a dock station. At home, they will plug their phone (iOS, Android, whatever) to their dock station and it will behave as a Desktop. And it will be good enough for everything they do.
The fact that Android complains and tells any app that asks whether the owner actually, you know, owns the device they paid for is an implementation detail.
A Linux distribution that adopts an Android style security model could easily still provide the owner root access while locking down less trusted apps in such a way that the apps can't know or care whether the device is rooted.
But that does not mean that all OSes should be open source. I think it's fine for iOS to be proprietary, but there should be enough information for someone to write an entire alternative OS that runs on iPhone. I think it should be illegal to prevent that (is it called tivoisation?).
All that to say, I don't believe that having root on my Android system is a right. But being able to install a system that gives me root should be one. If that system exists, that is.
I want to be able to do what I want with my PC or phone. I don't want every app on my PC or phone to be able to do whatever they want, without me agreeing first.
But that does not mean that I should be able to do whatever I want with any OS I install. If I am not happy with Android, I can install LineageOS and modify it the way I want.
I am obviously not a big fan of Google, but I do believe that AOSP is actually a good deal (a lot better than iOS which is proprietary). Google is doing a lot of work on AOSP. That I cannot unlock/relock the bootloader on some devices is not Google's fault.
And that's the part that I believe should be a right: if you buy a smartphone, you own that piece of hardware, and you should be able to install the system you want. But if you are not the one developing that system, you don't get to decide what this system does. Just like you don't get to decide whether Microsoft Word can export to PDF or not.
I'm saying that despite all they get right, the Android and Apple security models, when foisted on the mass market, are socially and ethically flawed. I'm saying that the end user has a fundamental right to tamper with the software on his own system. Those designing an OS that intentionally thwarts the user's will are in the wrong.
Just because something is legal that doesn't mean doing it is a good thing.
For "normies", it feels like the existing security model is actually not that bad. I can't imagine what would happen if everybody was running something without any sandboxing.
> I can't imagine what would happen if everybody was running something without any sandboxing.
I don't think anyone implied that? Having root or signature spoofing or even the ability to install kernel modules doesn't imply anything about the rest of the security model.
Second thing is: if you have root and change something on the system, you break the secure boot. So you fundamentally cannot have full access, can you?
That's why my opinion is that it's not Google's role to make everyone happy. They should just not be allowed to prevent alternatives. So that the rounding error minority can install the system they want and be happy with it.