HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
72% Positive
Analyzed from 2290 words in the discussion.
Trending Topics
#flatpak#access#app#file#program#desktop#directory#permissions#sandboxing#software
Discussion (41 Comments)Read Original on HackerNews
When you install something via Flatpak, it still changes data in god-knows-what places on my disk. And the software itself has read/write access to god-knows-where on my disk.
The answer is probably "convenience and efficiency". But I would much prefer a "An application is a directory and by default cannot access anything outside of that directory" approach.
Most software needs access to user files. Since most applications aren't written with Flatpak in mind, they will attempt to load files using their own file browser, meaning that for the application to function at all it needs to have access to swaths of extra data. You can see what data the application can access either via FlatSeal or in whatever "app store" you're using. Often it'll be your entire home directory.
The software that is designed with Flatpak in mind will use XDG Desktop Portals, where the host displays a file browser and then hooks it up to the sandboxed app so it has access only to that file or directory.
Note that you can't magic your way out of this. You can't eg. wait for the program to request access to a file before displaying a "Program wants access to this file. Allow/Deny" because the program doesn't know if this file exists, and the user wouldn't be able to navigate to it via the program's bespoke file browser since it doesn't have access to directories or their contents.
What stops the OS from granting access to read the directory structure by default, but not read/write its contents? It’s imperfect, but better than the alternative.
Also, macOS does it somehow, or at least seems to. I get the prompt you’re describing all the time as of a few years ago (I’m fuzzy on when it started)
Not much, it is entirely possible to do. But it also does have security implications like exposing SSH keys and such, which is why something like this isn't the default for flatpak. Though IIRC in a recent GUADEC or LAP(? too many talks recently happened) there were talks about moving "flatpak v2" to be either fully sandboxed and portal usage is a hard requirement or having the app basically be entirely unconstrained with probably only /usr/ or /opt/ mounted over or something like that (I think).
This isn't always easy and a lot of software on flathub is old-ish, so people tend to open up permissions since it's difficult to implement all these features properly. In my experience people will rarely stand in your way if you try to improve a package.
Restricting an app to not have file system access is a breaking change. It would have been dead in the water if they didn’t meet half way and make file system access an optional permission.
That makes sense if the application is the only program that needs to interact with the data. For example: If you have a drawing or photo editing program. You might have downloaded an image from the internet or from your camera. Then you make some edits. Afterwards you want to send the image to someone else via e-mail, which is another program.
E.g. the app does EnumerateDirectories("~/photos") then without requiring modification to the app, the call is interecpted, the user is presented with a permission request UI, and once granted, the app continues?
At least that's how I'd thought it would work. Perhaps this isn't viable?
If neither compatibility nor resources are of concern then integrating true Mandatory Access Control into both the UX and the entire tech stack would be the best way forward.
Nothing should change, all installations and addons go to the ~/.var directory. When you launch the application, yes it can start reading and writing to arbitrary places on disk, which is why I make it a habit of first launching Flatseal to modify permissions and know exactly what it can and can't do and reach.
I actually vastly prefer this methodology with what we have right now, but if it or something else adopted an application/directory methodology as you described I'd be elated.
We feed for 30 years constantly money into monopolies. We shall feed the next century constantly money into things the people need.
Many developers of Linux and GCC are paid. Because companies decided it is necessary.
On your last point, I'd love one day to see that OSS developers are paid because society benefits from their work.
Portals are just a terrible design for a security boundary: all interfaces clobbered up into one huge daemon, which also deals with a lot of the internals of Flatpak/Snap. If you want your sandbox to use portals, you can't, because it relies on internals of both of these sandboxing mechanisms. The devs have confirmed they won't implement an API for other sandboxing engines to integrate with them.
The whole system also deeply intermixes the package manager and sandboxing engine — to the point where you can't use the sandboxing engine with your favourite package manager, and you can't use the package manager without the sandboxing engine.
It seems that the mentality is: all other distributions are irrelevant, all other sandboxing engines are unsupported.
And then desktop applications start having first-class integration with Flatpak, and start having issues everywhere else.
You already need to set up Flatpak's daemons for using some features in Firefox (like screen sharing, where the native interfaces aren't supported), and it seems that the plan is to do the same for other features.
On the security side it was also seen as the only way forward, but it's just opt-in sandboxing. That's still possible to achieve without flatpak by using the underlying sandboxing tool (bubblewrap), but not as user friendly as using the flatpak provided defaults.
The box' cost already topped the project's budget so no new disk for it. I'm back to "proper .deb packaging please"
During installation they're _mentioned_ but the you can't pick which permissions to grant. If the developer requested it, its granted by default.
There are third party tools to tinker with permissions, but even those tools follow a "implicit grant first, revoke later" model, mostly because of how Flatpak implicitly grants permissions.
This is just wrong. Clients like the flathub website or gnome software show the risk posed by wide ranging access to local files, but Flatpak has to support legacy applications that don't use portals yet and thus they can't block applications having those permissions
https://flathub.org/en-GB/apps/com.calibre_ebook.calibre
> calibre is potentially unsafe
> Full file system read/write access
> Can read and write all data on the file system
If you prefer other ways of installing your software, that fine. But I really hope flatpaks continue improving and become the de facto way of installing desktop applications across all Linux distributions. For a normal, non-technical user installing and updating software should be easy, and I believe that flatpak provides this.
"For Modal, a robust app sandboxing story is essential to creating a Free Software OS that is competitive with modern mobile platforms."
Why? Focus should be desktop, not mobile.
We have enough mobile stuff that creeped in already.
I'm currently on macOS, and while I can cross-compile applications, I can't actually bundle them as Flatpaks. For that, I need `flatpak-builder`, which is so deeply coupled to Linux itself that I don't think it can realistically run on other platforms.
Snaps have a similar issue with `snapcraft`. However, you can still build a snap manually with `mksquashfs`, whereas I haven't found an equivalent low-level option for Flatpak. I may be missing something, though, and I'm still looking.
More and more I have found myself simply using podman and dockerfiles finding that building nix systems simply gets error prone and annoying and all the containerization systems leave a lot to be desired. Though I have some custom scripts for utilizing btrfs snapshots to create different nix store snap shots for containers or vms running with nix stores with virtiofs. This works quite well but not ready to be released and fiddly when things break and requires BTRFS.
I do agree flatpak and friends are not great though.
It's also not doing runtime sandboxing at all. Isolated builds protect you from supply chain attacks but not malware or vulns in the actual code, and they don't do anything for closed source apps.
Flatpak runs everything in a container with access limited to what is declared in the manifest and you can restrict it even more with Flatseal. It's not as secure as a Firecracker VM but it works way better than any other package system on Linux when it comes to security and distro independence.
GUI apps on NixOS rarely care about sandboxing so while you can do it yourself i bet almost noone does. Flatpak is trying to give you basic protections out of the box.
Now i have media organizer programs that deletes my files if i try to write on a networked drive. Games that can’t see the controller. Chat apps that can’t see attachments. Music app that can’t save at all. Good luck accessing any binary and using it in a script.
A waste of money if you ask me.
I think there are much more important issues that should deserve money and attention.