As shown by CVE-2019-5736, it is sometimes possible for the sandbox
app to access outside files using /proc/self/exe. This is not
typically an issue for flatpak as the sandbox runs as the user which
has no permissions to e.g. modify the host files.
However, when installing apps using extra-data into the system repo
we *do* actually run a sandbox as root. So, in this case we disable mounting
/proc in the sandbox, which will neuter attacks like this.
(cherry picked from commit 468858c1cbcdbcb27266deb5c7347b37adf3a9e4)
When installing a flatpak with extra-data we execute the apply_extra
script from the flatpak to extract the extra data files we
created. This script runs with very little filesystem acces, but it
does have write permissions to the location that will eventually be
/app/extra in the finished flatpak. This is especially problematic for
the systemwide install case, because the script is then run as root,
so it could potentially create a setuid file there.
Such a file would not be usable inside the sandbox (because setuid is
disabled in the sandbox), but it could potentially be a problem if the
user could be tricked into running the file directly on the host. This
is the same behaviour as e.g. rpm or deb which both can install setuid
files, but we want to guarantee that flatpak is better than that.
The fix is to run the script with all capabilities dropped (bwrap
--cap-drop ALL) which removes a bunch of possible attack vectors (for
instance setting file capabilities). However, even without
capabilities, it is possible for a user to make any file setuid to the
same user, so we also need to canonicalize the permissions of all
files generated by running the script.
Additionally, while running the script we set the toplevel directory
only be accessible to the user, meaning we will not temporarily leak
any potential setuid files to other users.
Note, this commit actually goes furthen than that and completely
canonicalizes all the file permissions to be the same as those
otherwise used by flatpak. For example we fix up cases where the
script creates files writable or unreadable by non-root users.
Closes: #2323
Approved by: alexlarsson
(cherry picked from commit 35598f46a5)
If you have a pre-existing remote configured its exact definition
might differ from the one specified in a flatpakrepo file and yet
be the same.
For example, i have:
$ flatpak --user remotes -d
Name Title URL Collection ID Priority Options
flathub Flathub https://dl.flathub.org/repo/ org.flathub.Stable 1
Yet when i install a flatpakref:
$ flatpak --user install http://flathub.org/repo/appstream/org.gnome.gedit.flatpakref
The application org.gnome.gedit depends on runtimes from:
https://dl.flathub.org/repo/
Configure this as new remote 'flathub-1' [y/n]:
Because the flathub flatpakrepo does not yet have the collection id specified.
So, we need to be more lenient when matching the pre-configured remotes.
Closes: #2324
Approved by: alexlarsson
(cherry picked from commit 1ce0246b0d)
This commit adds a key called DeployCollectionID to the flatpakref and
flatpakrepo file formats, which is intended to replace the CollectionID
key (which is still supported but deprecated). The reason for the change
is the same as for the metadata key change from xa.collection-id to
ostree.deploy-collection-id, which is that old versions of Flatpak
(roughly 0.9.8 through 1.0.1 depending on compile time options) hit
various bugs when collection IDs are in use. Flathub will soon enable
the metadata key to deploy collection IDs, and this change means Flathub
can also deploy the collection ID in flatpakref and flatpakrepo files
without affecting old clients.
Adding DeployCollectionID to the flatpakref and flatpakrepo files will
mean the flathub remote can be automatically configured with a
collection ID without depending on the metadata key to do that.
Closes: #2329
Approved by: alexlarsson
(cherry picked from commit 348fcc3f97)
We generate various configuration files for each sandbox instance,
and expose them to the sandbox using flatpak_bwrap_add_args_data,
which in the end passed --bind-data to bwrap. These files are not
sensitive or shared, but it still doesn't really make sense for
the sandbox to allow them to be modified, so lets switch them
to --ro-bind-data.
This affects these files in the sandbox:
$HOME/.var/app/$APPID/config/user-dirs.dirs
/etc/group
/etc/ld.so.conf
/etc/passwd
/etc/pkcs11/modules/p11-kit-trust.module
/etc/pkcs11/pkcs11.conf
/etc/timezone
/run/flatpak/ld.so.conf.d/*.conf
/run/user/$UID/pulse/config
/run/user/$UID/Xauthority
(cherry picked from commit a71f6ef13b)
We mistakenly bind-mounted the runtime /usr/etc files read-write in
/etc, which means that application could modify some parts of the
runtimes (at least when using a per-user installed runtime). Fix
this by using a --ro-bind.
(cherry picked from commit 08e47e9544)
If some installation is empty (or otherwise broken) we fail the
entire run command, even though the app might exist in e.g. the
user installation. This is a regression from
651c86d3c6 which also ended up in 1.0.4.
Explain that it is possible to install from a
local repo by passing the location.
Closes: #2245
Approved by: alexlarsson
Closes: #2247
Approved by: alexlarsson
If we use a remote name containing questionable characters
such as newlines or '[', we will run into assertions in
GKeyFile. To avoid that, check that the group name we
pass is valid, and throw an error otherwise.
Found while writing tests.
Closes: #2244
Approved by: alexlarsson
Closes: #2247
Approved by: alexlarsson
Some remote metadata can cause changes to the local configuration for a
remote, but Flatpak is not properly reloading the new config after
making changes. Specifically in flatpak_transaction_update_metadata() we
call flatpak_dir_update_remote_configuration() for each remote and then
try to reload the configuration by calling flatpak_dir_recreate_repo().
The problem is that while this reloads the config instance stored by the
repo member of the FlatpakDir, the FlatpakTransaction object still has
FlatpakRemoteState objects stored which were initialized from the old
config.
A consequence of this is that if a remote repository has the
"ostree.deploy-collection-id" key set in its metadata, the next
install/update operation from that remote will fail with the error
message "Can't pull from untrusted non-gpg verified remote", and then
subsequent operations will succeed. This is because during the first
operation Flatpak will add the collection ID to the local configuration
in flatpak_transaction_update_metadata() but then in
flatpak_dir_install() the outdated FlatpakRemoteState object will be
used which still has no collection ID.
So this commit frees all the stored FlatpakRemoteState objects on the
transaction, so they will be recreated when they're needed (based on the
new config).
Closes: #2243
Approved by: alexlarsson
(cherry picked from commit ce78f52fcc)
Currently, if flatpak_installed_ref_get_latest_commit() returns NULL
(which means the ref doesn't exist in the local repo) we assume any
remote commit could be an update in
flatpak_installation_list_installed_refs_for_update() when a collection
ID is not configured on the remote. When a collection ID is configured,
if get_latest_commit() returns NULL it causes a crash in
ostree_repo_load_commit(). So this commit prevents the crash and makes
the behavior in the post-collection-id world consistent with the
behavior in the pre-collection-id world.
It's difficult to write a test for this that's not contrived, without
knowing what circumstances led to the disappearance of the ref from the
repo.
Fixes https://github.com/flatpak/flatpak/issues/2216Closes: #2229
Approved by: alexlarsson
(cherry picked from commit 6b4402b60e)
In version 0.99.1 (065053775b) flatpak
stopped inheriting permissions from the runtime, because that made
the story about application permissions way to complicated. What
we want is to have a static set of permissions for the app that
is frozen at install time.
However, inheriting permissions from the runtime makes a lot of sense
as certain permissions are required from the runtime, in particular this
is used by the kde runtime to read the kdeglobals file, etc.
So, to combine the best of the two worlds, we now do inherit permissions,
but at build-time (and you can disable it if you want). This way
kde apps don't have to repeat themselves, but we still get static
application permissions.
Closes: #2230
Approved by: alexlarsson
(cherry picked from commit 99fbbc25c6)
This exposes a /etc/timezone with the current timezone, as per the old
debian spec: https://wiki.debian.org/TimeZoneChanges
In case we're using the session-helper this will be extracted from
the host config and applied whenever that changes.
Normally timezone info is specified by /etc/localtime being a symlink
into the locale data, and you can look at the symlink value itself.
However, in the sandbox we can't update a symlink in /etc at runtime,
nor can we make it of the canonical form as that would point into the
runtime. This is why /etc/timezone is used.
This fixes https://github.com/flatpak/flatpak/issues/2190Closes: #2214
Approved by: alexlarsson
(cherry picked from commit 0b6844f39e)
flatpak_installation_modify_remote was not saving the nodeps
state. Found while writing FlatpakTransaction tests.
Closes: #2198
Approved by: alexlarsson
(cherry picked from commit de56d34104)
This was found while writing transaction tests.
We were passing error, but trying to use the local_error
message.
Closes: #2198
Approved by: alexlarsson
(cherry picked from commit adf896d794)
We were emitting the ::operation-done signal with
different arguments than declared for the signal.
This showed up as test failure when comparing
the result argument.
Closes: #2187
Approved by: alexlarsson
(cherry picked from commit 3f0eb7e481)
Instead of FLATPAK_ERROR_ABORTED, return G_IO_ERROR_CANCELLED when the
passed in GCancellable gets cancelled. This makes it possible to cancel
updates in gnome-software without getting a generic "Aborted due to
failure" error popup.
Closes: #2178
Approved by: alexlarsson
--device=all really means the device nodes, we should not expose the host
shared memory objects.
This change incidentally fixes issues with --device=all on debian (#2136)
where /dev/shm is a symlink to /run/shm, which doesn't exist in the sandbox.
Closes: #2160
Approved by: alexlarsson
