When we're talking about a "mode", sometimes we mean a
FlatpakFilesystemMode, sometimes we mean a FlatpakFilesystemMode that
must be strictly greater than NONE, and sometimes we're willing to
accept the FAKE_MODE constants too.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 115d82e6ff)
This gives us the ability for the parse function (the former verify
function) to carry out a normalization step as well.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 517ad25b5f)
We weren't distinguishing here between overrides that should have been
negated (xdg-documents) and overrides that should not have been negated
(everything else).
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 4e3d1d8b7b)
(cherry picked from commit 74f02d1e95)
This tests for invalid metadata, missing xa.metadata and mismatched
values in xa.metadata and the real metadata, including the embedded
null leading to the hidden permissions of CVE-2021-43860.
(cherry picked from commit 2c2ce58c54b3e6c62f9c21c15efa0ba22f4bc09b)
(cherry picked from commit ce0bb56c6f)
If we have a bundle without metadata we wouldn't properly present
the permissions in the transaction.
(cherry picked from commit b250541302187ff2209b0bb1295e8223d0af860f)
(cherry picked from commit 574cb11372)
This was disables a long time ago because the fedora remotes didn't
contain metadata, but that has been added since then. Requiring fixes
a security concern where an app claims to require no permissions (by
having no metadata in commit) but then actually requires permissions
in the installed app.
(cherry picked from commit f0f3a35f404b5bd533186095db055f8b3d135576)
(backported from commit bd6948c375)
If we fail to parse xa.metadata from the summary cache or the commit
xa.metadata we fail the resolve.
If xa.metadata is missing in the commit we fail the resolve (it is
always set in the summary cache, because summary update converts
missing xa.metadata to "", so we either get that, or cache miss which
leads to resolving from the commit.
This means that op->resolved_metadata is always set during install and
updates, which means we will show the app permissions. The transaction
will also always make sure that this data actually matches what gets
deployed.
Before this change an invalid metadata in the summary cache could lead
to a NULL resolved_metadata, which means we wouldn't print the app
permissions, yet we would still deploy some metadata file that could
have permissions. (NOTE: It would fail to deploy unless the
xa.metadata in the commit matched the metadata file, but in this
corner case we would't compare the summary and commit metadata, so
they may differ.)
(cherry picked from commit 5036bca4214d5b77e884dec42e36496a06e74081)
(backported from commit 10367bd7d2)
In particular, if a null terminator is placed inside the metadata file,
Flatpak will only compare the text *before* it to the value of
xa.metadata, but the full file will be parsed when permissions are set
at runtime. This means that any app can include a null terminator in its
permissions metadata, and Flatpak will only show the user the
permissions *preceding* the terminator during install, but the
permissions *after* the terminator are applied at runtime.
Fixes GHSA-qpjc-vq3c-572j / CVE-2021-43860
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
(cherry picked from commit c9c3a667c09a846c0b230cf1cc8ed330028aa03c)
(backported from commit 3c3dc554e7)
For updates in remotes with a local (file:) uri we just do a deploy
with a LOCAL_PULL flag set and an empty arg_repo_path. However, our
arg_repo_path checking at some point seemed to stop properly handling
the case where it is empty. I got it to report "No such file" wich
broke the tests.
(cherry picked from commit 49e8bfcea5)
(cherry picked from commit c8b9069ab1)
Fixes: #4339
The soup backend and the curl backend give slightly different error
messages, so we need to tweak the 404 assert check to match both.
(cherry picked from commit 9914dff925)
(cherry picked from commit 8a6a22e24a)
This works with newer versions of pyparsing, while producing generated
files common/flatpak-variant{,-impl}-private.h identical to those produced
by the old variant-schema-compiler when using the pyparsing versions in
Debian 10 and Debian 11. Backporting this commit allows older branches
to be CI-tested successfully.
Fixes https://github.com/flatpak/flatpak/issues/4534
(cherry picked from commit 6cb4a2598e)
(cherry picked from commit a0d8a1dcf3)
(cherry picked from commit 1dbc175314)
[smcv: verified that this has no effect with older pyparsing versions]
If we do, it interferes with xdg-dbus-proxy, causing test failure under
some circumstances: the test passes on a development system, but fails
when run on a qemu virtual machine in Debian's autopkgtest framework.
Fixes: 6e5b02e2 "run: Don't let XDG_RUNTIME_DIR from user override the value we set"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7bf6ecfaa2)
(cherry picked from commit 9c12cb44b8)
We use `bwrap --setenv XDG_RUNTIME_DIR` to set it to `/run/user/UID`,
regardless of what it is on the host system, but the changes made
to resolve CVE-2021-21261 unintentionally broke this by overwriting it
with the user's XDG_RUNTIME_DIR.
In practice this worked for most people, who either have
XDG_RUNTIME_DIR set to the same value we use (which is the conventional
setup from systemd-logind and elogind), or entirely unset (if they do not
have systemd-logind or elogind). However, it broke Wayland and other
XDG_RUNTIME_DIR-based protocols for people who intentionally set up an
XDG_RUNTIME_DIR that is different.
Fixes: 6d1773d2 "run: Convert all environment variables into bwrap arguments"
Resolves: https://github.com/flatpak/flatpak/issues/4372
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit d3e6e71fee)
Distributions run these tests on other architectures, but hard-coding
x86_64 to look for in output dooms that to failure.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ba381ae936)
(cherry picked from commit 4089b69769)
Just because we can allocate a new, unused fd in the portal's fd space,
that doesn't mean that fd number is going to be unused in the child
process's fd space: we might need to remap it.
Resolves: flatpak/flatpak#4286
Fixes: aeb6a7ab "portal: Convert --env in extra-args into --env-fd"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 526dae9241)
(cherry picked from commit 101a3c5515)
This will allow us to add additional mapping entries for fds to be
used internally by `flatpak run`, in particular --env-fd.
Defer the second pass through the fd array until the last possible
moment, so that any extra fds we want to add (like the --env-fd) have
already been added by then.
Helps: flatpak/flatpak#4286
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit a09d07f085)
(cherry picked from commit 77b484cb2e)
Otherwise we'll run out of file descriptors eventually, when starting
a sufficiently large number of subsandboxes.
Resolves: flatpak/flatpak#4285
Fixes: aeb6a7ab "portal: Convert --env in extra-args into --env-fd"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit f2fbc75827)
(cherry picked from commit b4c6aa1cc8)
This was incorrectly looking at errno instead of -r.
Fixes: 0b38b0f0 "run: Handle unknown syscalls as intended"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3fc8c67267)
(cherry picked from commit 97e128c2c1)
The error-handling here was
if (r < 0 && r == -EFAULT)
but Alex says it was almost certainly intended to be
if (r < 0 && r != -EFAULT)
so that syscalls not known to libseccomp are not a fatal error.
Instead of literally making that change, emit a debug message on -EFAULT
so we can see what is going on.
This temporarily weakens our defence against CVE-2021-41133
(GHSA-67h7-w3jq-vh4q) in order to avoid regressions: if the installed
version of libseccomp does not know about the recently-added syscalls,
but the kernel does, then we will not prevent non-native executables
from using those syscalls.
Resolves: https://github.com/flatpak/flatpak/issues/4458
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit d419fa6703)
(cherry picked from commit 270701f900)
If we don't allow pivot_root() then there seems no reason why we should
allow chroot().
Partially fixes GHSA-67h7-w3jq-vh4q.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we don't allow mounting filesystems, we shouldn't allow unmounting
either.
Partially fixes GHSA-67h7-w3jq-vh4q.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we don't allow unshare() or clone() with CLONE_NEWUSER, we also
shouldn't allow joining an existing (but different) namespace.
Partially fixes GHSA-67h7-w3jq-vh4q.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we don't allow mount() then we shouldn't allow these either.
Partially fixes GHSA-67h7-w3jq-vh4q.
Thanks: an anonymous reporter
Signed-off-by: Simon McVittie <smcv@collabora.com>
clone3() can be used to implement clone() with CLONE_NEWUSER, allowing
a sandboxed process to get CAP_SYS_ADMIN in a new namespace and
manipulate its root directory. We need to block this so that AF_UNIX-based
socket servers (X11, Wayland, etc.) can rely on
/proc/PID/root/.flatpak-info existing for all Flatpak-sandboxed apps.
Partially fixes GHSA-67h7-w3jq-vh4q.
Thanks: an anonymous reporter
Signed-off-by: Simon McVittie <smcv@collabora.com>
Historically, syscalls could take arbitrarily-different values on
different architectures, but new syscalls are added with syscall numbers
that align on each architecture.
Signed-off-by: Simon McVittie <smcv@collabora.com>
At the moment, if we block a syscall we always make it fail with EPERM,
but this is risky: user-space libraries can start to use new replacements
for old syscalls at any time, and will often treat EPERM as a fatal error.
For new syscalls, we should make the syscall fail with ENOSYS, which is
indistinguishable from running on an older kernel and will cause fallback
to an older implementation, for example clone3() to clone().
In future we should probably move from EPERM to ENOSYS for some of the
syscalls we already block, but for now keep the status quo.
This is a prerequisite for fixing the vulnerability tracked as
GHSA-67h7-w3jq-vh4q.
Signed-off-by: Simon McVittie <smcv@collabora.com>
For whatever reason parts of mono is installed, but the repo is not
configured so there is a version conflict on update:
libglib2.0-cil is already the newest version (2.12.45-0xamarin19+ubuntu1604b1).
libglib2.0-cil set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libglib2.0-cil-dev : Depends: libglib2.0-cil (= 2.12.10-6) but 2.12.45-0xamarin19+ubuntu1604b1 is to be installed
E: Unable to correct problems, you have held broken packages.
(cherry picked from commit b6d5e20857)
This is either a malicious/compromised app trying to do an attack, or
a mistake that will break handling of %f, %u and so on. Either way,
if we refuse to export the .desktop file, resulting in installation
failing, then it makes the rejection more obvious than quietly
removing the magic tokens.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 46b3ede524)
If we add new features analogous to file forwarding later, we might
find that we need a different magic token. Let's reserve the whole
@@* namespace so we can call it @@something-else.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 1e7e8fdb24)
This passes -fsanitize=address in the right place.
Passing it this way instead of CFLAGS allows us to strategically
not add sanitize in specific places as needed.
(cherry picked from commit 97a153fe0a)
This means we can systematically pass the environment variables
through bwrap(1), even if it is setuid and thus is filtering out
security-sensitive environment variables. bwrap ends up being
run with an empty environment instead.
As with the previous commit, this regressed while fixing CVE-2021-21261.
Fixes: 6d1773d2 "run: Convert all environment variables into bwrap arguments"
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit fb473cad80)
This means we can systematically pass the environment variables
through bwrap(1), even if it is setuid and thus is filtering out
security-sensitive environment variables. bwrap itself ends up being
run with an empty environment instead.
This fixes a regression when CVE-2021-21261 was fixed: before the
CVE fixes, LD_LIBRARY_PATH would have been passed through like this
and appeared in the `flatpak build` shell, but during the CVE fixes,
the special case that protected LD_LIBRARY_PATH was removed in favour
of the more general flatpak_bwrap_envp_to_args(). That reasoning only
works if we use flatpak_bwrap_envp_to_args(), consistently, everywhere
that we run the potentially-setuid bwrap.
Fixes: 6d1773d2 "run: Convert all environment variables into bwrap arguments"
Resolves: https://github.com/flatpak/flatpak/issues/4080
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980323
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9a61d2c44f)
