Firejail and apparmor have existed for years. If you don't use them maybe it's your fault?
Also the very same npm backdoors have already hit android apps. What can sandboxing do if you backdoor a dependency of your banking app?
Also the very same npm backdoors have already hit android apps. What can sandboxing do if you backdoor a dependency of your banking app?
"Your car does not come with a seatbelt? Seatbelt parts are easy to order online and assembled on any car, it's your fault for not using one."
> Also the very same npm backdoors have already hit android apps. What can sandboxing do if you backdoor a dependency of your banking app?
The whole point of sandboxing is that one compromised app can not compromise the whole system and other apps. Compromised dependency on my banking app on Android or iOS only compromises that banking app and nothing else.
Fedora is notable because any software installed via repositories has a policy written for it, so it is already far more in effect than you might realize.
It's entirely comparable to Android sandboxing because it's part of the foundation of Android sandboxing.
Flatpak is primarily a convenience mechanism for app makers. Any security boundary you may find in it is optional, all defaults are always toward not breaking apps. Apps pretty much uniformly either silently get read access to all your files, and even when that is not true they often get permanent read-write access to any file you open in them.
Go look at the permissions for GNOME Papers. Try to argue that it's "sandboxed".
This is outdated information. The situation has improved since the publishing of flatkill with flathub loudly warning about permissions and less apps having full R/W access.
Android apps can be configured insecurely too although less severe, still it's the users responsibility to check and modify permission.
In either case it's a substantial improvement from no isolation at all with much easier handling than other sanbox tools or MACs.
Not good enough when apps can still silently have full access to home and /media without the user even realizing.
A lot of it is probably standards and culture work, like where a user can expect to store files and have them readable by Firefox in this example. So perhaps this is something the GNOME/Freedesktop people could have been interested in and made a difference? Instead we have things like Flatpak, which is good but not the lowest hanging fruit here.
It's also not like Linux is any different with respect to installing random PyPI/npm packages on any other desktop/laptop OS (https://xkcd.com/1200/), so I'm not sure anything desktop Linux does here would change the fact that installing random software from the internet may be a bad idea sometimes ;)
Granted, I'm viewing this as far easier than the sandbox "fake file system" approach? Firefox would be able to see the file exists, most likely, but just not have read rights to it. Yes, you can have some things it can't list, but I would expect that to be low on probability to want to attach to an email?
Linux desktop environments had the chance to set a precedent here where software could for example have had a directory named after the application under the user's home, and use subuid to access files. That is simply an example, but would be a backwards compatible way to create a shared culture how Linux desktop software operate, and easen a transition where desktop software could be limited to "their" own directory.
Instead they squandered this chance by focusing all effort on moving dotfiles around (.config was such a waste of energy where we the heated debate could have been about something more useful, such as the above). Now we have Snap and Flatpak which both try to solve a culture problem (where we store our files) with technical solutions (bind mounts! modal gui:s! popup dialogs!). These will not improve the situation. In the best case it will train users to click "Yes" more, which we know not to help security.