On Mon, Jun 5 2023 at 02:09:58 PM -0400, Steve Grubb <sgrubb@xxxxxxxxxx> wrote:
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 [1] for a discussion of this.
[1] https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html
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 have?
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.
Michael _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
