
Flatpak – A Security Nightmare (2018) - fao_
http://flatkill.org/
======
thayne
> A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to
> this vulnerability. Flatpak developers consider this a minor security issue.

The actual wording in the linked release is "This is a minor security update,
matching the behaviour on master where we avoid ever creating setuid files or
world-writable directories." The wording is perhaps a little ambiguous, but my
interpretation of that is, "this is a minor update that fixes a security
issue," not "this is an update that fixes a minor security issue." The author
also implies that simply including a setuid binary would allow the app itself
to get elevated privileges. This seems at odds with the way flatpak uses
containers to sandbox the app, and in fact when I looked at the linked CVE,
the actual vulnerability is that a _seperate attack_ could use a setuid binary
installed as part of a flatpak to get privilege escalation. Don't get me
wrong, it's still a sever vulnerability. But it is much more difficult to
exploit than the author first led me to believe.

~~~
choeger
Add to that the first paragraph, which is literally a complaint that flatpack
does not make things better compared to rpm.

Indeed the one about security updates is valid and my biggest grievance with
such an approach. Note, however, that propietary software like sublime could
easily use statically linked or embedded libraries anyways, as they do not
have to adhere to any packaging guidelines. So this applies only to free
software that has been packaged with the distro.

~~~
vetinari
> Indeed the one about security updates is valid and my biggest grievance with
> such an approach.

And that stems from misunderstanding.

Flatpak has a concept of runtimes. If you have some basic library that would
be updated by your distribution, you have pretty much big chance that it would
be part of the runtime and updated by runtime maintainers, not by the
application authors.

I.e. you would get your security updates, subject to the maintenance period of
the runtime (for example, the org.freedesktop.Platform has 2-year support).

~~~
danieldk
_If you have some basic library that would be updated by your distribution,
you have pretty much big chance that it would be part of the runtime and
updated by runtime maintainers, not by the application authors._

Unfortunately, this is not true. Many of the Flathub Flatpaks compile custom
versions of a lot widely-used libraries. E.g., the most recently updated
Flathub package of an open source project (as of writing), compiles by itself
[1]:

Boost 1.73, Eigen 3.3.7, OpenCV 4.3.0, exiv2 0.27.2, marble 20.04.1, lensfun
0.3.2, ImageMagick 7.0.10-13, libgphoto2 2.5.25, libusb 1.0.23, jasper 2.0.16,
libksane 20.04.1, sane-backends 1.0.27, libqlr master, qtav 1.13.0, x265 3.3

Most of these are standard dependencies that are in most Linux distributions.

[1]
[https://github.com/flathub/org.kde.digikam/blob/2d0b5b369382...](https://github.com/flathub/org.kde.digikam/blob/2d0b5b369382afa08074bc72b34774c022fe15ef/org.kde.digikam.json)

~~~
vetinari
Widely used does not mean, that they are good candidate for a platform
library. Many of them do not have stable API, so you either keep everything on
an ancient version (hopefully compilable against), or stuff breaks.

E.g. Boost. Fedora 32, which was released this April, but has version 1.69
(released in Dec 2018), while the current one is 1.73. Similarly, ImageMagick
is updated every few days. In these cases, it is better to let the
applications decide which versions they want, and keep up with updates.

------
blendergeek
Unless this has been updated since 2018 (it doesn't have a date but also looks
like it still from 2018) it should be marked [2018].

Also: Here is previous discussion from around the time this website was
created:
[https://news.ycombinator.com/item?id=18180017](https://news.ycombinator.com/item?id=18180017)

~~~
nominated1
> Unless this has been updated since 2018

I think this might also apply to Flatpak.

Has Flatpak addressed any of these concerns? If so, how?

~~~
arghwhat
That's not how this works. Old content is marked with its year, irrespective
of its relevance.

------
LeoPanthera
This page is really old, but I disagree with "the users are misled to believe
the apps run sandboxed".

I think most people use flatpak (and/or snap, appimage, etc.) as a way of
installing applications in a way that does not contaminate the host OS, and a
way of removing them again without leaving any traces behind.

For example, it's an extremely convenient way of installing Steam without
having to worry about its obscure, 32-bit, dependencies.

That they are sandboxed, or not, is very much secondary, for most users, I
believe.

~~~
gentleman11
What I know about flatpak was from some Linux you tubers who led me to believe
it was a sandbox. For that matter, some hn users posted similar things in the
last month when talking about snaps iirc

~~~
vetinari
Flatpak has a sandbox; but for some apps, it has to be a more open, otherwise
they would not work as intended. All that's open is visible as a flatpak
permission; if you want, you can tighten it up and see, what breaks.

On the other side spectrum are people, that are disappointed, that they cannot
use SDKs installed at random places in their host system with editors packaged
with Flatpak. Well, duh...

------
evross
A great talk on Flatpak sandboxing was released in March. [1]. The original
post is from 2018 (Flatpak 1.0). Not sure if these issues are completely fixed
yet, there are a lot of release notes up to version 1.63 (stable). [2] It
seems that the maintainers and community are working on improving security
continuously. My main hope is that they optimize for privacy, security and
user control of the packages. Overall I'm impressed by flatpak with it's
cross-distribution packaging.

[1]
[https://www.youtube.com/watch?v=3rCIEzfZw1I](https://www.youtube.com/watch?v=3rCIEzfZw1I)

[2]
[https://github.com/flatpak/flatpak/releases](https://github.com/flatpak/flatpak/releases)

~~~
mongol
Did you see it live? Not a great experience on Youtube, audio problems
unfortunately.

~~~
evross
I found it through search on Youtube, had been looking for which way to
package applications on Linux. Packaging really takes a bit of time, reading
documentation and figuring out how to do it. After packaging a flatpak you
need to add it to a local repository on your device before you can test
install it, which isn't as intuitive as clicking on a .appimage file, but
brings some benefits. The documentation is quite readable:
[https://docs.flatpak.org/en/latest/first-
build.html](https://docs.flatpak.org/en/latest/first-build.html).

Agreed for audio quality. It's hard to listen to with only the left channel
working. It might be worth reuploading it with balanced stereo.

------
gavinray
Am I the only person who actually doesn't really mind that flatpaks and snaps
have less user-control over behavior and/or security implications?

I really enjoy them. Install it, forget about it, let it update automatically.

Theoretically could something unwanted happen, yeah probably, but I enjoy the
convenience they provide and typically you're installing fairly well-known
software (Microk8s, VS Code, and Chromium come to mind).

My one gripe with snaps is that AppArmor can occasionally cause headaches with
Microk8s permissions.

~~~
lmm
If you don't care about user control, why would you be using Linux at all?
When you hit a bug in a flatpak or snap, what are you going to do? E.g. on
Linux you now just can't input Japanese text in Slack and there's no way to
fix this.

~~~
lboc
Could you elaborate on the Slack-Linux-Japanese thing please?

I have no problems with it, and was wondering if maybe an update broke it?

~~~
lmm
See e.g. [https://forum.snapcraft.io/t/cant-use-input-method-in-
snap-a...](https://forum.snapcraft.io/t/cant-use-input-method-in-snap-
apps/4712/50) . Certainly it was broken for years, and if it's been fixed then
that's only very recently.

------
bepvte
I still love flatpak, and much of what this article states is hostile and
outdated. The "XDG portal" specification makes filesystem access less popular
then before. Also, "fakepak"? Really?

------
axaxs
I don't understand why people favor Snap or Flatpak to Appimage, which looks
to be the simplest of the three. Would anyone mind sharing their experiences?

~~~
self_awareness
My experience is that AppImage solves problems of Flatpak and Snap, but
doesn't introduce any problems from these two.

I don't see why AppImage wouldn't be able to be updated if support for this
would be added to the app itself.

When trying to download software that doesn't exist in my distro's repo, I
always look for AppImage first.

~~~
PlutoIsAPlanet
Because AppImage doesn't solve the problems.

\- No sandboxing

\- Doesn't solve the "run everywhere" problem, AppImages usually are compiled
agaisnt Ubuntu LTS's, which isn't 100% binary compatible with other distros,
e.g. fedora

\- Its a game of bingo whether the AppImage has a library bundled or not, and
whether the app will work your host version or not.

\- Performance, appimages are a compressed filesystem that getss mounted by
fuse each time the app is run, which is slow, additionally subsequent launches
of the app aren't even faster because we get fresh inodes each launch.

\- Bad system intergration, appimaged is an abomination.

\- AppImages promote a bad security practice of marking binaries from the web
as executable, let's not replicate the main way malware is distributed on
Windows.

------
inshadows
As opposed to what? To how I run GIMP in the past? Certainly not.

> Look ma, I've discovered a program can do nefarious things

What else is new?

~~~
Gaelan
I mean, there's an argument that this is worse. If a security bug is found in
libc, in the "old world," your distro would have an update out in a day, and
you'd be completely safe. With flatpak, you also depend on whoever's
maintaining the GIMP flatpak (and all your other apps), who may not be
motivated to do updates any faster than GIMP's normal release schedule,
potentially leaving you vulnerable for much longer.

~~~
outsomnia
> your distro would have an update out in a day, and you'd be completely safe

If you do not restart your services after updating the package, your services
continue to run against the exact libs they were started with, even though the
library is updated on disk and anything new that starts will use the fixed
version. For something like the libc, that is pretty much every service
bringing it in and still running the unpatched version of the library.

Updating distro packages is of course usually a good thing, but alone it does
not make you "completely safe".

Also they have a patched version "in a day" because they embargoed public
release of the vuln details usually for months, creating a gap where a
(growing...) set of people know a secret that can compromise your system and
you don't. When I get that update I don't feel "completely safe".

------
jsnell
So Flatpaks also install under /var? That's horrible, I thought it was only
Snaps that made that decision :( Does anyone know what the official reasoning
for this is?

~~~
bepvte
Flatpaks use a git-like tree of hashes, which cant just be shoved into random
places on your filesystem. It has an exports directory you can symlink or add
to your path.

~~~
mikepurvis
In that case it should be in /opt, where application bundles not managed by
the system's primary packaging system belong.

~~~
Spivak
This isn’t technically correct when Flatpak is installed via your
distribution. Then it _is_ managed by your packaging system and it’s data
should live in a /var/lib.

/opt is for software that doesn’t adhere to the FHS and can’t/shouldn’t be
installed in a prefix. Red Hat and Arch install software to /opt via their
official package managers. /opt isn’t safe to stick arbitrary software even
though it’s commonly used for that — /opt/local is the non-FHS equivalent of
/usr/local.

------
thecureforzits
Independent of the technical issues being discussed I find this site to be an
interesting example of the politics around open source development. It is run
anonymously (out of albania, presumably to avoid whois lookups) and does not
link to responses or opposing points of view. In addition it is posted
regularly on various technology sites such as reddit, HN, etc.

------
akho
Flatpak mixes together application packaging, sandboxing, desktop integration,
and an update mechanism. I do not understand the need to have all four in the
same tool. I even think it limits the usefulness of each component.

Would a combination AppImage, firejail, and a couple of shell scripts be
worse?

~~~
dylan-m
Much worse. I encourage you to try some properly sandboxed Flatpak apps.
Here's a fun one:

[https://flathub.org/apps/details/com.github.maoschanz.drawin...](https://flathub.org/apps/details/com.github.maoschanz.drawing)

Note that the app has no access to your home directory by default, and this
fact is invisible to the end user. The file open and save dialog is handled
out of process by a portal, which is a service that allows an application to
(with permission) poke holes in its sandbox. By tying a few different things
together, this is seamless: the user gets a file chooser dialog and chooses a
file, as usual. (As a bonus, it's always a native dialog). Behind the scenes,
the application is granted access to read or write to that file.

I don't think this would be easy to manage if Flatpak was split into a bunch
of different moving parts, and I can't imagine it providing any meaningful
benefit.

With that said, it isn't as monolithic as folks seem to think. It's built on
bubblewrap and ostree and a whole bunch of freedesktop specifications.

------
Thorrez
> The criticial vulnerability "shell in the ghost" was fixed in flatpak about
> one month after linux distributions.

I can't find any reference to that vulnerability except this page.

~~~
pmontra
The name isn't an exact match but maybe it's this glibc vulnerability:

[https://blog.qualys.com/laws-of-
vulnerabilities/2015/01/27/t...](https://blog.qualys.com/laws-of-
vulnerabilities/2015/01/27/the-ghost-vulnerability)

Edit: nope, this is Ghost in the Shell, from last February

[https://www.microsoft.com/security/blog/2020/02/04/ghost-
in-...](https://www.microsoft.com/security/blog/2020/02/04/ghost-in-the-shell-
investigating-web-shell-attacks/)

~~~
Thorrez
I don't think either one is right.

That first one is from Jan 2015, but according to Wikipedia the first release
of Flatpack was Sept 2015. The second one doesn't even seem to be a
vulnerability, but rather the general concept of web shells. One of the
vulnerabilities mentioned in the article (CVE-2019-0604) is for Microsoft
SharePoint, so that's unrelated to Flatpack. Also note the difference in order
of the words "ghost" and "shell".

------
steerablesafe
Packaging your software in Flatpak/snaps/appimage:

Pros:

You have 100% control of your dependencies.

Cons:

You have 100% responsibility for your dependencies.

In short: more control implies more responsibility.

------
bonestormii_
The moment you delegate your security or stability concerns to a third party,
all bets are off. Period. Package maintainers, RedHat, whoever.

Maybe the patch fixes a vulnerability, maybe it creates one. Maybe the company
pushing security is really pushing mindshares of ecosystems for subscription
revenue and industry influence.

Build from source; keep your packages as minimal as possible; keep your
permissions as granular and restricted as you can manage; and pray to your
gods of choice.

I can't understand why people are so anxious to embrace so much unneeded
complexity. Things that "just work" always just work until they just don't.

~~~
kelnos
I'm pretty sure "build from source" is out of reach for most people (from a
technical ability standpoint), and for those who could do that, most have
better things to do with their time.

If your threat model includes intentionally malicious packages from Red Hat,
Debian, or whomever, ok, but understand that you're a miniscule fraction of a
percent of the user base. And you'd better be auditing the source that you
compile as well.

~~~
ownagefool
The words "threat model" gets thrown around, but I'm not actually sure "our
threat model didn't include our OS vendor" would be considered an acceptable
excuse.

Sure, we have reasons to trust Redhat;

\- You can look at their working practices ( Good coding hygiene, Peer Review,
Tools, etc )

\- You can make the commercial argument ( they make money by doing the right
thing, it's not in their interest to hack us )

But ultimately we're still explicitly trusting 1000s of people here, so
reality is much more nuanced.

\- Hardern your OS, i.e. only install the bare essentials.

\- Monitoring for processes or networking traffic doing unexpected things.

Thus, you evidence that you reasonably trust the vendor but you'd expect to
see an alert were to prove false.

Probably a better use of "threat model" would be, we don't need to place trust
in developer end user devices because we instead place our trust in our SCM,
CI/CD and the SDLC process.

~~~
kelnos
> _The words "threat model" gets thrown around, but I'm not actually sure "our
> threat model didn't include our OS vendor" would be considered an acceptable
> excuse._

I can't recall any threat-modeling session I've been a part of, or any infosec
security professional I've talked to, who has seriously considered the OS
vendor as a threat. "Our threat model didn't include the OS vendor" absolutely
_is_ an acceptable excuse.

Your mitigations (only install bare essentials, network monitoring) are good
advice in general, and people should be doing those things regardless of any
perceived threat from the OS vendor.

Aside from that, really the only way you can absolutely harden yourself
assuming a hostile OS vendor is to... not use an OS, and build your entire
system from scratch. Which, again, sure, might be a perfectly reasonable thing
to do for some ultra-sensitive applications, but -- again -- that is a teeny
tiny fraction of a percent of what's actually happening out in the world.

~~~
ownagefool
First point, depends on what you work on I guess. Most of the world doesn't
patch, but that doesn't mean managing your dependencies isn't important.

On the last point, doing it all yourself probably isn't actually better. Most
people don't have the time in the day to invent the universe, so you're always
back to figuring out how you establish trust.

------
gentleman11
> Yes, it's possible your linux box has been compromised if you use flatpak,
> we are literally talking about several months old public exploits. Ever
> opened an image in flatpak Gimp? The criticial vulnerability "shell in the
> ghost" was fixed in flatpak about one month after linux distributions.

There were some heavily up voted comments and posts on hn this year about how
much people hate how snaps auto update themselves. Does this change anyone’s
mind, or do those points still stand?

~~~
AlexandrB
Those points are completely unrelated to flatpak taking a long time to release
patches. Whether flatpak forced updates or not, from TFA it seems as though
it's still months behind Linux distros.

------
Iolaum
This article is written in bad faith.

RE: The sandbox is a lie. No it's not. The technical capabilities are there.

The problem is that the application needs to be written a certain way in order
for the sandbox to be enforced and the app not to break. This is a not a
technical problem but a political and resource one. Meaning how do you
incentivize developers to re-write their apps so that they are compatible with
that. Given that there are very few money to be made in linux applications I
can see why developers are not rushing to re-write. Hence flatpak's allow for
an escape hatch on the sandbox so existing apps continue to work. Even Google,
with all of it's influnce on the android ecosystem, and all the money involved
in it had to back off on scoped storage last year because of the developer
outcry. Flatpak is moving towards the right direction. But because of lack of
resources it 'll take more time to get there.

RE: You are NOT getting security updates

Again the author mixes technical capability with the limitations of a
volunteer driven ecosystem to arrive to a bad conclusion. In 99% of cases
flatpaks are provided by third party volunteers. They have no obligation to
stop their life in order to test and provide timely updates. This is also true
for normal deb/rpm packages by the way. Maintainers of complex packages such
as calibre are unsung heroes. However flatpak's architecture allows for
software vendors to host their own repositories and it's easy for the user's
to subscribe to them. Hence if a software vendor wants to provide timely
updates to their users the capability is there and waiting.

RE: Local root exploit? Minor issue!

Hello Nitpicking. thayne did a better job than I could do in their post
([https://news.ycombinator.com/item?id=23523887](https://news.ycombinator.com/item?id=23523887)).
At the end of the day an update was provided for the users addressing this. As
a user I don't care about how the update was sold. I saw an update available
and I updated my system.

TLDR: Flatpak technical capabilites are fine (or working towards the right
direction). The ecosystem does not have the resources to emberace those
capabilities fast enough and that's been used to diminish the technical work
been done.

~~~
pie_flavor
This is a tool. How good it is, is measured by how useful it is to me. If it
does not provide something I need it to do, then it's less good for it. If it
fails to provide the services it advertised as providing, then it's straight-
up bad. I don't care _why_ this happens. Might be technical, might be
political, might be resource based. Doesn't matter. The tool either does what
I need it to or doesn't. And flatpak does not provide sandboxing or security
updates, and that it doesn't do this is independent of whether it's a
technical or non-technical problem.

~~~
Iolaum
It's one thing to criticise flatpaks on the grounds of not getting the job
done because nobody uses it properly and another to say there's no sandbox.

------
arminiusreturns
I will use appimage. I refuse to use flatpak or snaps. That's my take as a
linux user and admin.

