Shall I plug NixOS?
Nix packages and NixOS services have no easy sandboxing features. There is no improved security in current Nix or NixOS.
Flatpak – a security nightmare – 2 years later (2020)
231–240 of 296 posts
Re: Flatpak – a security nightmare – 2 years later (2020)
#232Earlier quoted context omitted.
A capability model fixes this: the application launches a file chooser which it does not control , which can then return it an fd or other token giving the application the capability to read from or write to a specific file. Of course, this would be a considerable effort. But it's probably where we're going.
Flatpak already does this. It is called portal. The grandparent post is wrong. The problem is what haplens when the program does not use standard file choosers, file APIs, etc.
Can't the sandbox override the corresponding syscalls? E.g. open() and readdir() which then block until the user has selected the file? This means you'll have to click the file twice (once for the sandbox and once for the application) but at least it is more secure.
Re: Flatpak – a security nightmare – 2 years later (2020)
#233Earlier quoted context omitted.
I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…
From my perspective as a Flatpak user I can say I hate how the current file access restrictions are implemented, it's confusing and annoying. I use a messenger installed via Flatpak. So whenever I receive a file in it I cannot save it anywhere outside my Downloads folder. So every single time I then have to open a file manager and manually move the file somewhere else. Similar for the other way around - I have to cop…
This way of dealing with file-access is also not secure: if all your files eventually end up in a Downloads folder which is readable by all Flatpak apps, then what advantage does this have over sharing your entire home folder?
Re: Flatpak – a security nightmare – 2 years later (2020)
#234Earlier quoted context omitted.
What is Nix and why is it a better alternative?
There is some overlap and there are a lot of differences. One point of overlap is that Nix makes it easy to install packages that are newer than your os. For example, you could run NixOS 20.09 or Ubuntu 16.04 and have the latest Handbrake or youtube-dl. A large difference it that Flatpak also attempts to sandbox applications, which Nix doesn't (it only sandboxes builds). Though it might be easier to sandbox applicati…
There's a larger amount of overlap with https://spectrum-os.org/ (which builds on Nix). https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kv... is also really interesting (and discusses Nix and SpectrumOS) and itself was discussed at https://news.ycombinator.com/item?id=26378854
Re: Flatpak – a security nightmare – 2 years later (2020)
#235Response from a Flatpak package maintainer - https://theevilskeleton.frama.io/2021/02/11/response-to-flat... I'll leave others to make their own minds up, but I personally think the original article is FUD in a similar vein to some of the SystemD and Wayland nonsense that gets upvoted occasionally.
I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…
>The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many.
The response article did also note that the most popular flatpak apps are often ones that really need filesystem access in order to function properly, e.g. an IDE, an image editing program, an audio editing program, etc.
It's really hard to conceive of how these programs would work without some of the requested permissions. I remember the hazards of trying to get a proper IDE on ChromeOS some years back because of Google's own sandbox restrictions on allowing extensions to access the chromebook's filesystem. IIRC there was a company that even created "cloud-IDE" environments to get around this limitation.
Re: Flatpak – a security nightmare – 2 years later (2020)
#236Earlier quoted context omitted.
The technological ludditism is exhausting. We know some things are *objectively* better than the status quo. With attack surface as big as a modern browser or media player, not having sandboxing would be a mistake. Just the people who are stuck to 1970's way of doing things and fear new things oppose sandboxing.
I have run the browser on a separate user account for years
I don't understand why this isn't more popular.
This has been the sandboxing method or choice since the 70s. Filesystem permissions were designed around users and groups, and now everybody's trying to bolt on intra-user access control lists and wondering why the experience sucks so much.
Create a `browser` user. Add yourself to the `browser` group. Maybe give `browser` read access to an area in your docs folder for convenience. Modify your browser launch script. Done.
Re: Flatpak – a security nightmare – 2 years later (2020)
#237If Flatpak security is this much of a joke, why do people go through the trouble of using it? Flatpaks are outright cumbersome, and bar-none my least favorite way to install anything. Have a local GTK/Qt theme/colorscheme? Gotta manually patch it in. Have a small main drive? You can store maybe three or four Flatpak'd apps. Slow internet connection? Good luck, you'll be here a while. All of it boils down into the outright worst way to distribute software on Linux. I'd rather use Snaps, which should be taken as a violent insult to anyone who's familiar with the medium. Nowadays, if I see that an app is exclusively distributed through Flatpak, I'll compile it from source or find an alternative.
The future of software cannot be containerizing anything dangerous or complicated. All it does is add an extra layer of abstraction that makes it harder for the end-user to use your software. All of this seems especially redundant on Linux, where we could take any number of extreme measures to sandbox software. Why did we choose the path of most resistance for the user?
Re: Flatpak – a security nightmare – 2 years later (2020)
#238Somebody wrote a response to this: https://theevilskeleton.frama.io/2021/02/11/response-to-flat...
This response is pretty well-measured, but their closing note rubbed me the wrong way.
>If you don’t like Flatpak for personal reasons, I respect your opinion, but basing your arguments on an anonymous post that claims to have “criticized” Flatpak, but provided no statistics or evidence that vulnerabilities have been exploited inside a Flatpak package is not a reliable source of information.
Really?
You can't categorize people into "people who use flatpak" and "people who have personal reasons", it's not a very healthy way to look at software development. These concerns are entirely legitimate, and it's not like you're coming from the majority here. Flatpaks are still wildly unproven, and most of their responses were concessions surrounding the issues Flatpak has.
Re: Flatpak – a security nightmare – 2 years later (2020)
#239Earlier quoted context omitted.
Perhaps make it an optional setting? "Enhanced Sandboxing (Warning: This feature is experimental, and may cause issues for some apps.)" or something of the sort.
It is... you can add/remove any paths you like. The default errs into what users are used to. See also threads bellow; people complaining that the Signal client can save only into ~/Downloads.
Makes sense. I use flatpaks only very lightly, I apologize for not checking before opening my mouth :)
Re: Flatpak – a security nightmare – 2 years later (2020)
#240Earlier quoted context omitted.
I don't agree with your assessment at all. The linked article seems to mostly agree with the criticism levied, but disagrees mainly with the severity and degree of the issues. For example, OP says: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissio…
>The response says that no, not "almost all"; out of the 50 surveyed apps, 23 of them had excessive permissions. Well, ok, sure, that's definitely not "almost all", but that's still way too many. The response article did also note that the most popular flatpak apps are often ones that really need filesystem access in order to function properly, e.g. an IDE, an image editing program, an audio editing program, etc. It'…
Yes. I tried using a flatpak of PyCharm and it blocked access to directories where some of my code’s dependencies lived. It was unusable.