> VLC [...] filesystem=host
See my comment on why it's not easy to fully sandbox software like VLC: https://news.ycombinator.com/item?id=14409234
The author is correct, in the fact that flatpak-vlc is not a secure sandbox.
Flatpak – a security nightmare
31–40 of 264 posts
Re: Flatpak – a security nightmare
#32"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.
Re: Flatpak – a security nightmare
#33Is the sandboxing of flatpak more or less secure than docker?
They use a lot of similar techniques. One big difference is that docker uses user namespaces and flatpak does not. I'n not sure about the reasoning, but it's probably a combo of "not trusting user namespaces" (disagree) and user namespaces requiring privileges to use. It sounds like the bigger issue isn't that the underlying technologies are fundamentally better or worse, but that the de facto configurations are wors…
Yes. The sandbox tool used by Flatpak is "bubblewrap", which has an overview here: https://github.com/projectatomic/bubblewrap/blob/master/READ...
There is nothing against Flatpak using user namepsaces when the developers feel a bit more comfortable with that, though.
Re: Flatpak – a security nightmare
#34> Sadly, it's obvious Red Hat developers working on flatpak do not care about security, yet the self-proclaimed goal is to replace desktop application distribution - a cornerstone of linux security. Sheesh, while the issues raised are all valid, this does not actually justify such a conclusion about the intent of the Red Hat developers. Telling people what their side of the story is for them in a dismissive fashion l…
Yes, his other major gripe is that the security updates for non-official flatpaks take a while to get security releases out. I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos. The same thing with Alpine Linux packages. Its not a problem with the tech, its a lack of volunteers (or not yet enough adoption by…
> his other major gripe is that the security updates for non-official flatpaks
I don't know whether it is true or not, but the author explicitly states that it is the official applications AND runtimes that aren't properly maintained.
> I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos
No you don't, because either (a) the package was not uploaded to the official (main) debian repository or (b) the debian security team is in charge of fixing it if the maintainer is no longer available.
Re: Flatpak – a security nightmare
#35I share this writer's concerns with Flatpak. It looks to me like yet another attempt to bring the horribly broken and insecure "download it and drag it to your desktop" model of application distribution, which has long been a source of viruses and malware on Windows and Macs, to Linux.
This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained. In other words, Linux is secure because nobody can ship software on it without going through massive hurdles and because everybody who is smart enough to install software on Linux does some diligence.
> This isn't any less "broken" than painstakingly adding third-party repositories when your package happens to not be maintained.
True, it isn't any less broken than that; it's more broken.
First, adding a third-party repository, and then using your distro's GUI package manager to install an app from that repository, is a lot more work for the average user than clicking on a download link and then dragging the downloaded file to your desktop (or clicking on it to open it and start an install process). That's by design: it should take some work on the user's part to download and install software that hasn't been vetted by their distro. Greatly reducing that work, as Flatpak does, is a bug, not a feature. (See further comments below.)
Second, third party repositories don't promise that their apps are sandboxed; a binary from a third-party repo has the same privileges as any other binary from the distro. Users aren't being told that the third party apps are "more secure". Promising that your apps are sandboxed means they need to actually be sandboxed; disabling the sandbox with default privilege settings breaks that promise. So users get less security than they think they are getting with this model.
> Linux is secure because nobody can ship software on it without going through massive hurdles
Really? Then why are there thousands of open source applications in my distro's package manager? (And that's without installing any third party repositories.)
> everybody who is smart enough to install software on Linux does some diligence.
Nothing can protect a user who is not smart enough to do some due diligence before installing software. So setting up the system to require some due diligence seems like a better idea than removing the due diligence just because users will find that easier, and then claiming that you can still provide security.
Re: Flatpak – a security nightmare
#36Earlier quoted context omitted.
Well they’re “free” if you buy them alongside hosting. Still even if cheap, that’s quite a commitment: finding a domain, paying it, writing a custom (albeit simple) website, uploading it, etc...
> Well they’re “free” if you buy them alongside hosting. Depends on hosting company. I've "bought" domains for free many times, without hosting, just to run joke sites for few months.
Ha, interesting! I always assumed a .org was at least a dollar. Mind sharing a link?
Re: Flatpak – a security nightmare
#37Earlier quoted context omitted.
File picker is privileged and mediates access through monitor. Ditto for drag-and-drop. Problem (largely) solved.
Do you open your files in PyCharm or VSCode through a file picker?
Drag and drop project folder. Also, yes, I do open project directories using PyCharm's (poor) file picker.
Re: Flatpak – a security nightmare
#38Earlier quoted context omitted.
File picker is privileged and mediates access through monitor. Ditto for drag-and-drop. Problem (largely) solved.
Do you open your files in PyCharm or VSCode through a file picker?
I’d imagine once you open a directory you can open files within it (and child dirs)
Re: Flatpak – a security nightmare
#39To be honest, this security nightmare also covers other contemporary "container" formats such as docker.
Running docker containers as a non-root user is unfortunately still not a widespread practice. That means that any root process within a docker container has root on the host.
Re: Flatpak – a security nightmare
#40Earlier quoted context omitted.
Yes, his other major gripe is that the security updates for non-official flatpaks take a while to get security releases out. I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos. The same thing with Alpine Linux packages. Its not a problem with the tech, its a lack of volunteers (or not yet enough adoption by…
> his other major gripe is that the security updates for non-official flatpaks I don't know whether it is true or not, but the author explicitly states that it is the official applications AND runtimes that aren't properly maintained. > I have the same problem when I run applications that have an official RPM repo, and a volunteer packages the deb and pushes it to the official Ubuntu/debian repos No you don't, becaus…
The Debian security team being responsible may help you figure out who to blame, but it doesn't magically help the update actually happen. The Debian security team is a volunteer team, and it's entirely realistic that someone may actually have seen delays in the packages they care about getting security updates. "No you don't" is arrogant - you have no way of knowing that.