caedda5b2a
With Flatpak you should only have to trust each remote to provide good updates for the apps provided by it. However the P2P support in OSTree considers each remote to be equally trustworthy, which opens a possible attack vector. For example if I have a flathub remote configured and apps installed from it and I also have a remote "sketchy-remote" configured which I have one app installed from, I expect the Flathub apps to update from Flathub (or to update from LAN/USB sources with Flathub GPG signatures) and not from the sketchy-remote. The way this attack would play out is that the sketchy-remote would deploy the same collection ID as the victim remote (in this case org.flathub.Stable) in order to serve updates for it. So this commit mitigates the issue by using the new "ref-keyring-map" option added to libostree[1], which means that pulls of updates to Flathub apps will always be verified using the Flathub GPG keyring, even if they're coming from another source like another configured remote or a LAN/USB source signed with the malicious remote's keyring. In the latter case the pull from the malicious source will fail, and flatpak should then do a successful pull from a legitimate source. We use the "ref-keyring-map" option in both flatpak_dir_do_resolve_p2p_refs() and repo_pull() because if we only use it in the latter place the ref could be resolved to the malicious commit (which would be checked with the malicious keyring), and then in repo_pull() we would try unsuccessfully to pull the malicious commit from the legitimate remote. Since pulls into the system installation already use the correct remote's keyring (see the use of ostree_repo_verify_commit_for_remote() in flatpak_dir_pull_untrusted_local()) this mitigation is only needed for per-user installations (or other scenarios that circumvent the system helper). It's also only needed since the commit "dir: Fix an edge case of resolving collection-refs" because before that commit this attack vector wasn't exploitable. Unfortunately this implementation is not perfect, because there's not always a one-to-one mapping between configured remotes and GPG keyrings. On Endless OS some remotes have keyrings in /usr/share/keyrings/ rather than /var/lib/flatpak/repo/remote_name.trustedkeys.gpg as do remotes added by Flatpak. However presumably you would only add a keyring to a global directory if you trust it to the same extent as the others. A subsequent commit will add a unit test for this. Fixes https://github.com/flatpak/flatpak/issues/1447 [1] https://github.com/ostreedev/ostree/pull/1810 Closes: #2705 Approved by: alexlarsson
Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux.
See https://flatpak.org/ for more information.
Community discussion happens in #flatpak on Freenode and on the mailing list.
Read documentation for the flatpak commandline tools and for the libflatpak library API.
Contributing
Flatpak welcomes contributions from anyone! Here are some ways you can help:
- Fix one of the issues and submit a PR
- Update flatpak's translations and submit a PR
- Improve flatpak's documentation, hosted at http://docs.flatpak.org and developed over in flatpak-docs
- Find a bug and submit a detailed report including your OS, flatpak version, and the steps to reproduce
- Add your favorite application to Flathub by writing a flatpak-builder manifest and submitting it
- Improve the Flatpak support in your favorite Linux distribution
Hacking
Flatpak uses a traditional autoconf-style build mechanism. To build just do
./autogen.sh
./configure [args]
make
make install
To automatically install dependencies on apt-based distributions you can try
running apt build-dep flatpak and on dnf ones try dnf builddep flatpak.
Dependencies you will need include: autoconf, automake, libtool, bison,
gettext, gtk-doc, gobject-introspection, libcap, libarchive, libxml2, libsoup,
gpgme, polkit, libXau, ostree, json-glib, appstream, libseccomp (or their devel
packages).
Most configure arguments are documented in ./configure --help. However,
there are some options that are a bit more complicated.
Flatpak relies on a project called Bubblewrap for the
low-level sandboxing. By default, an in-tree copy of this is built
(distributed in the tarball or using git submodules in the git
tree). This will build a helper called flatpak-bwrap. If your system
has a recent enough version of Bubblewrap already, you can use
--with-system-bubblewrap to use that instead.
Bubblewrap can run in two modes, either using unprivileged user
namespaces or setuid mode. This requires that the kernel supports this,
which some distributions disable. For instance, Debian and Arch
(linux kernel v4.14.5
or later), support user namespaces with the kernel.unprivileged_userns_clone
sysctl enabled.
If unprivileged user namespaces are not available, then Bubblewrap must be built as setuid root. This is believed to be safe, as it is designed to do this. Any build of Bubblewrap supports both unprivileged and setuid mode, you just need to set the setuid bit for it to change mode.
However, this does complicate the installation a bit. If you pass
--with-priv-mode=setuid to configure (of Flatpak or Bubblewrap) then
make install will try to set the setuid bit. However that means you
have to run make install as root. Alternatively, you can pass
--enable-sudo to configure and it will call sudo when setting the
setuid bit. Alternatively you can enable setuid completely outside of
the installation, which is common for example when packaging Bubblewrap
in a .deb or .rpm.
There are some complications when building Flatpak to a different
prefix than the system-installed version. First of all, the newly
built Flatpak will look for system-installed flatpaks in
$PREFIX/var/lib/flatpak, which will not match existing installations.
You can use --with-system-install-dir=/var/lib/flatpak to make both
installations use the same location.
Secondly, Flatpak ships with a root-privileged PolicyKit helper for
system-wide installation, called flatpak-system-helper. It is D-Bus
activated (on the system bus) and if you install in a non-standard
location it is likely that D-Bus will not find it and PolicyKit
integration will not work. However, if the system installation is
synchronized, you can often use the system installed helper instead—
at least if the two versions are close in versions.
This repository
The Flatpak project consists of multiple pieces, and it can be a bit challenging to find your way around at first. Here is a quick intro to the major components of the flatpak repo:
common: contains the library, libflatpak. It also contains various pieces of code that are shared between the library, the client and the services. Non-public code can be recognized by having a-private.hheader file.app: the commandline client. Each command has aflatpak-builtins-source filedata: D-Bus interface definition filessession-helper: The flatpak-session-helper service, which provides various helpers for the sandbox setup at runtimesystem-helper: The flatpak-system-helper service, which runs as root on the system bus and allows non-root users to modify system installationsportal: The Flatpak portal service, which lets sandboxed apps request the creation of new sandboxesdoc: The sources for the documentation, both man pages and library documentationtests: The testsuitebubblewrap: Flatpak's unprivileged sandboxing tool which is developed separately and exists here as a submodulelibglnx: a small utility library for projects that use GLib on Linux, as a submoduledbus-proxy: a filtering proxy for D-Bus connections, as a submodule