On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb
Yes. And how does it's security model work?
The security model is that the application is assumed to be compromised
by malicious input and is trying to do evil things to the host system,
like read your home directory and send copies of your files to a
ransomware operator or nation state. Linux namespaces plus seccomp
filters are used to confine applications to prevent them from messing
with the host system, or reading your personal files, etc.
It's great in theory. Problem is, as a transition measure to encourage
developers to adopt Flatpak, you can give your application extra
permissions that totally break the security model, and this is
extremely common in practice. You should only trust applications that
don't do this, but most apps do. See  for a discussion of this.
There are different degrees of badness. E.g. Epiphany, which I
maintain, has a sandbox hole that allows it to read and write your
Downloads directory, and another hole that allows it to talk to
Geoclue. These are both unacceptable, but certainly not as bad as
allowing read/write access to the user's home directory or root
filesystem, which many apps actually do.
Flatpak could be pretty darn secure, but only if we stop allowing this,
and I fear that would likely result in applications abandoning the
platform. This is a major threat IMO. I'd love to see more effort
towards improving our portals so that applications don't need to use
static permissions anymore. We need to really clamp down on this so
that users can trust the Flatpak ecosystem.
What is the root of trust?
I think there is no root. A GPG key is provided when installing a
runtime or application.
Are they signed by a Fedora key that I already
Nope (except presumably for Fedora Flatpaks).
How can we verify it's integrity?
I think the GPG keys are trust-on-first-use.
Once installed, how do I verify it's
integrity? How do I check if anything has been modified?
I don't know. Non-Fedora Flatpaks are stored using ostree, so people
familiar with ostree would be able to answer this question. Fedora
Flatpaks are OCI containers, so people familiar with OCI containers
would know about that.
ostree is a "git for binaries" and you can detect normal non-malicious
modification by looking at the history, e.g. `flatpak remote-info --log
flathub org.gnome.Platform//44`; however, this only tells you when
something changed, not what actually changed.
Does it integrate
well with SE Linux,
No. selinux is entirely outside the Flatpak security model because
Flatpak is a cross-distro tool and selinux is not used outside Fedora
and Red Hat distros.
IMA, fapolicyd, or openscap?
I'm not familiar with these technologies, but I think the answer is: no.
On a locked down system, are
there sysctls that I have undo such as user namespaces?
Technically, Flatpak can work without user namespaces, but this is a
legacy configuration and it only works if bubblewrap (/usr/bin/bwrap)
is built to use suid root instead of user namespaces, which is not
recommend and which we do not do in Fedora. (I think Debian maybe still
does this?) So it will surely break if you disable user namespaces, but
you might be able to make it work by rebuilding your own bubblewrap
instead of using Fedora's.
The Flatpak sandbox does not attempt to guard against kernel bugs -- it
can't, because it has to allow access to all syscalls that applications
might reasonably want to use -- so if you don't trust the kernel to be
secure (including user namespaces), Flatpak is not the tool for you.
If an app coredumps,
does a problem report get generated? Who gets it?
Nope, there's nothing. You have to manually create a backtrace using
flatpak-coredumpctl and then create a bug report yourself. This is
really bad. We need ABRT to handle this so we can generate crash
reports like we do for Fedora's packaged software.