There are important points that I am making. Your response is concerning, and reflective of the problems I raise.
I’m not sure what you think is concerning about Sam’s response here, he pretty much describes what I thought when reading your reply to me…
I have not participated in this thread or even read it in detail but saw that you are struggling with changing the title and thought I should help, so I asked about the new title…
what i got in return was a multi paragraph answer unrelated to the title at all instead of an expected “please change the title to …” or an “I’d rather leave it as is”…
From your multi paragraph answer it is still not clear to me if you want it changed or not (or what to change it to if so)
Indeed you are just trying to be helpful, I apologise, most of what I have outlined here is mostly obvious and pointless or just re-iterated things I have said in the past.
Thank you for the help and good luck!
I’ve noticed a lot of your opinion is that the Flatpak sandbox is more robust. While I reckon I can guess why most peoples opinions are on that that (the permission system on Flatpak is far more flexible IMO), I think there’s a certain irony to claiming that the Flatpak sandbox gives less issues so it’s more trustworthy.
The entire point of a sandbox is to throw up walls and barriers. Conceptually, if I throw an app into a sandbox and don’t get errors, I’d be tempted to say one of the three following things:
- The app is designed/suitable for sandboxing anyway
- The apps needs are simple and sandboxing doesn’t interfere since nothing much is actually going on
- The sandbox isn’t doing as much as you think it is.
Unfortunately with Flatpak, I’m tempted to say the case is usually number 3. This comes down to:
- Permissions are only checked on initial upload, on future uploads, a flatpak on Flathub can redeclare its permissions freely, to the point the sandbox is effectively optional.
- The permissions are significantly looser. Things such as being able to edit
~/.bashrcare trivial in Flatpak and impossible in Snap. You won’t be able to declare permissions for.bashrcwithout this being pulled up in a review, and the review process won’t just give you it. - Flatpak even has an entire DBus API for passing the host/container boundary that is explicitly turned off in Snaps. To do this in Snap you’d have to find exploits, to do this in Flatpak you simply need to ask correctly.
It does sound though like a lot of the problems aren’t so much even the sandbox in the literal sense, but the general libraries/compatibility of the bases/extensions being used. Don’t let me come across as telling you these problems don’t exist; although I feel they’re likely to vary from app to app based on factors that end up being a little more than just the format. (e.g, the Freedesktop runtime is fundamentally just an entirely different distribution than the Core runtimes, libpulse might be entirely differently configured in one than the other!).
But I guess in summary where I’m going is, the Snap sandbox might be more annoying to deal with for the developer but I’m convinced the security results of this trade-off actually propogate to the users. I’m not convinced this happens so much with Flatpak as shown by just how many Flatpaks will for example mount the entire host filesystem just to avoid permission issues.
8 Likes
about the flatpak sandbox
I agree.
about the user experience with flatpaks
I would guess that you do not know the user experience of all flatpak users.
As a user I am also jumping through hoops with flatpak. If I do not trust a particular flatpak 1000%, I do not use it with my main user accounts. If I do not trust a certain repository (but the build definition is fine), I build the flatpak by myself. E.g. for the 3D slicing software I use it gets its own linux user account (which has no rights but the directories etc are readable by my main accounts). I hope that an attacker at least needs to have a privilege escalation to get to my data. Snaps have a different set of issues.