"Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions, that is, write permissions to the user home directory (and more), this effectively means that all it takes to "escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's it."
No shit, installed applications can write to the filesystem. What an exceptional security hole that only affects flatpak and literally every other form of installing those same programs outside of a sandbox.
If we could get applications to switch to using APIs backed by the xdg-desktop-portal, then they don't even get access to the host/home filesystems. They talk to a service which sends a FUSE FD to the app, and that overwrites the original file when close()d (but never does the app get direct filesystem access).
Gtk added GtkFileChooserNative for just this purpose. It implements the same file-chooser interface as other dialogs so in many cases is a couple line change to apps. Sadly, it can't be done automatically because various API/ABI reasons.
A document editor will want to write to the users documents directory.
Is the problem here that the user home dir both contains typical locations for user data and writing files with certain names to it will automatically execute ,such as ~/.bashrc?
Wouldn't it be better if the app only had permission to write to an actual user documents/data directory, rather than the home root? Which begs the next question: is there a standardized user document/data directory for desktop linux that isn't just "~"?
> Wouldn't it be better if the app only had permission to write to an actual user documents/data directory...
Well, would it? If the app went rogue, it could still encrypt all your documents.
Either way, dealing with that is not the job of package management or software installers. They can not solve the fundamental design issues of software that has been written without a finer permissions model in mind.
Yes, outside of a sandbox it's expected. But you don't sell something as secure and sandboxed when it's not. A flatpack sharing any part of the host file system with the app should be marked as insecure when installing and/or launching.
> Yes, outside of a sandbox it's expected. But you don't sell something as secure and sandboxed when it's not.
It is isn't being sold as "secure". It's sandboxed in the same way that Python virtual environment is sandboxed, i.e. you're not messing with the system software installation. Real security sandboxing is a completely orthogonal feature that package managers do not deliver either.
Honestly, that's not what I would expect sandboxed to mean. By that definition installation in /opt/$vendor/$software/$version would also be sand-boxed.
No shit, installed applications can write to the filesystem. What an exceptional security hole that only affects flatpak and literally every other form of installing those same programs outside of a sandbox.