This ensures that the command is not taken to be a bwrap option.
Resolves: CVE-2024-32462
Resolves: GHSA-phv6-cpc2-2fgj
Signed-off-by: Alexander Larsson <alexl@redhat.com>
[smcv: Fix DISABLE_SANDBOXED_TRIGGERS code path]
[smcv: Make flatpak_run_maybe_start_dbus_proxy() more obviously correct]
Signed-off-by: Simon McVittie <smcv@collabora.com>
The TIOCLINUX ioctl is only available on Linux virtual consoles such as
/dev/tty1. It has several Linux-specific functions, one of which is a
copy/paste operation which can be used for attacks similar to TIOCSTI.
This vulnerability does not affect typical graphical terminal emulators
such as xterm, gnome-terminal and Konsole, and Flatpak is primarily
designed to be run from a Wayland or X11 graphical environment, so this
is relatively unlikely to be a practical problem.
CVE-2023-28100, GHSA-7qpw-3vjv-xrqp
Resolves: https://github.com/flatpak/flatpak/security/advisories/GHSA-7qpw-3vjv-xrqp
Signed-off-by: Simon McVittie <smcv@debian.org>
There isn't much in the way of legit reasons for this, but it's a
potential security footgun when displaying the text.
CVE-2023-28101, GHSA-h43h-fwqx-mpp8
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
Co-authored-by: Simon McVittie <smcv@collabora.com>
This prevents someone from placing special characters in order to
manipulate the appearance of the permissions list.
CVE-2023-28101, GHSA-h43h-fwqx-mpp8
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
Before 1.8.0 (2016), gpgme used to have two different thread-safe builds,
one for use with POSIX-style pthread and one for use with GNU Portable
Threads (libpth), plus a non-thread-safe version. Since 1.8.0, this
complexity has gone away and there is only libgpgme, which is thread-safe.
In practice this meant that on modern distros since 2016, we would always
fail to detect gpgme via pkg-config and fall back to calling gpgme-config.
Library-specific -config scripts are generally considered problematic
for multiarch, multilib and cross-compiling, and the gpgme-config script
recently disappeared from GPGME's Debian packaging
(see https://bugs.debian.org/1022348 and https://bugs.debian.org/1023601),
so it's better if we can prefer to use pkg-config.
If gpgme >= 1.8.0 is not found, fall back to gpgme-pthread >= 1.1.8,
either discovered via pkg-config or via gpgme-config.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9b87e4c0d4)
(cherry picked from commit c8f3f0dc1a)
This already happens for installs due to the cleanup path in
`flatpak_dir_deploy_install()`, but it doesn’t happen for other calls to
`flatpak_dir_deploy()`. Notably, during updates of already installed
apps.
Specifically, this means that if an app update is cancelled due to being
blocked by a parental controls policy, the temp deploy dir for that app
(such as
`~/.local/share/flatpak/app/com.corp.App/x86_64/stable/.somehex-XXXXXX`)
will be leaked. It will never be automatically cleaned up, as it’s not
in `/var/tmp` either.
Fix that by using `glnx_mkdtempat()` to create a scoped temporary
directory.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
(cherry picked from commit ce1829a703)
flatpak_remote_state_lookup_ref() always sets the error to
FLATPAK_ERROR_REF_NOT_FOUND when it returns FALSE.
Found by coverity CID 1514265
(cherry picked from commit 12ebf8fd9a)
The systemd-userdbd service was added in systemd 245, which was
released in March 2020 and is available in RHEL 9. Therefore, it's
safe to assume that the systemd_userdbd_stream_connect() SELinux
interface is also available on all relevant operating systems, unless
there's reason to believe otherwise.
https://bugzilla.redhat.com/show_bug.cgi?id=2071217
(cherry picked from commit 4965e5d076)
It's clearly quite important to have read access to /var/lib/flatpak
and it's contents. This explicitly permits that to avoid running
into SELinux denials.
https://bugzilla.redhat.com/show_bug.cgi?id=2070741
(cherry picked from commit 8617ab0ad0)
The system-helper (ie., the `flatpak-system-helper` process) is
labelled with flatpak_helper_exec_t and runs in the flatpak_helper_t
domain, and needs to be able to read /etc/passwd. This explicitly
permits it to do so to avoid running into SELinux denials.
https://bugzilla.redhat.com/show_bug.cgi?id=2070350
(cherry picked from commit 002e4455d8)
This is specifically for running build-time tests in the Autotools build
system, and is not used when running installed-tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 597abdc585)
The subpath is resolved relative to the root of the commit, so we can
use either an absolute or a relative path interchangeably. When using
libostree < 2021.6 with GLib >= 2.71, absolute paths cause an assertion
failure here; that was a libostree bug and was fixed in 2021.6, but we
can interoperate with more versions by sticking to relative paths, and
there's no real reason to prefer absolute.
Resolves: https://github.com/flatpak/flatpak/issues/4805
Co-authored-by: Corentin Noël <corentin.noel@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2df1b1628c)
As with non-path-based AF_UNIX sockets, both of these are going to
require --share=network to be enabled, so print a warning if it isn't.
We don't automatically enable --share=network, because that elevates
the privileges of apps that would otherwise have entered a new network
namespace, but regular users of remote X11 can choose to enable it with
`flatpak run --share=network` or `flatpak override --share=network`.
Resolves: https://github.com/flatpak/flatpak/issues/397
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit db885e0542)
If the filesystem-backed Unix socket (G_UNIX_SOCKET_ADDRESS_PATH) does
not exist, X11 clients can also use a Linux abstract Unix socket
(G_UNIX_SOCKET_ADDRESS_ABSTRACT), or even a TCP socket.
Both of these are going to require --share=network to be enabled, so
print a warning if it isn't. We don't automatically enable
--share=network, because that elevates the privileges of apps that would
otherwise have entered a new network namespace, but users can make it
work with `flatpak run --share=network` or
`flatpak override --share=network`.
When falling back to an abstract Unix socket or to a TCP socket, we
can't remap the display number to the fixed :99.0 that we normally use,
so adjust write_xauth() to be able to avoid doing that.
Resolves: https://github.com/flatpak/flatpak/issues/4702
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 1d81d61053)
We still don't support rewriting XAUTHORITY for these, but at least we
understand them now.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 69f347e58a)
In practice, au_len comes from one of the length fields in an Xauth
struct, which are all of type unsigned short, so it cannot really be
negative; but if we passed a negative argument here, the comparisons
would not behave as intended. Use the more correct size_t.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2358d25684)
We're not going to call XauDisposeAuth on local_xa, so it's OK to put
a "borrowed" constant string here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 39823be84f)
It is already the case that when we are using ALL_DIRS, we always
combine it with OPTIONAL_REPO, meaning no need to populate empty
installations. ALL_DIRS is used for commands that iterate through all
known installations to enumerate apps/runtimes, such as `flatpak run`
and `flatpak list`; for these commands, it's reasonable to say that
if the installation does not have a libostree repository, then that's
equivalent to it having a libostree repository with no apps and no
runtimes. Make this happen automatically if forgotten.
For STANDARD_DIRS, we were inconsistent about this: `flatpak remote-list`
had OPTIONAL_REPO, but the other commands did not.
STANDARD_DIRS is used for `flatpak create-usb`, and for all the commands
that manipulate remotes.
For the commands that manipulate remotes, it seems reasonable to say
that if an installation has no libostree repository and we are unable
to create one, then that's equivalent to an installation with a
libostree repository but no remotes.
Similarly, for create-usb, an installation where we are unable to create
a libostree repository seems like it should be equivalent to an
installation whose libostree repository does not contain any of the
refs we are interested in.
Resolves: https://github.com/flatpak/flatpak/issues/4111
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3f144d1e02)
libostree makes heavy use of fd-based I/O, which has the disadvantage
that it is rarely obvious what path an error message is referring to.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit d106384446)
If we are running a CLI command in the background, then EnsureRepo
might require authorization. Silently skip it if allow_empty was true,
as it is for commands that iterate through all repositories.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 48f40d4504)
Previously, if /var/lib/flatpak didn't exist then we would use the
system helper to create and populate it, but if it existed and was empty,
we could only populate it if we had privileges. This led to errors from
libostree:
Creating repo: mkdirat: Permission denied
The EnsureRepo method call is allowed by default for active local users,
so do this even if allow_empty is true: this will incorporate
/etc/flatpak/remotes.d into the repository, whether it is newly-created
or not. This makes a `flatpak search` work immediately, without having
to fetch metadata explicitly.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2489b915ef)
This is a combination of these two commits from the main branch:
build-finish: Export appstream metainfo into a single directory
(cherry picked from commit 766bf5f08a)
Export to share/metainfo not share/appdata
(cherry picked from commit 3c63cac8f9)
However this commit only allows the exports when deploying an
install/update, not when building a new Flatpak, so we avoid a warning
message but arguably don't add any new features to the stable branch.
Fixes https://github.com/flatpak/flatpak/issues/4800
Put the configured server address string in PULSE_SERVER if it appears
to be remote. This should be enough for apps that already have network
access via --share=network.
If remote access to a PulseAudio server has been selected but the app
does not already have the --share=network permission, we don't want to
add --share=network automatically, because that would open up the app's
access to network resources, perhaps unexpectedly. However, users of
this non-default configuration can use `flatpak run --share=network` or
`flatpak override --share=network` to open up that access if they
consider it to be safe enough.
Resolves: https://github.com/flatpak/flatpak/issues/3908
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ee418c1f20)
In some OS configurations, unprivileged users cannot read back messages
that they have written to the system log. This test cannot succeed if that
happens, so skip it.
In particular, if the Journal is only in-memory rather than persisted
to disk (as it was by default in Debian 10), then there are no per-user
Journal files, only a single system-wide Journal which requires privileges
to read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: 8b05f6b3 "Add a unit test for the history command"
(cherry picked from commit 0deb80efa8)
All the details of the bug are in:
https://github.com/ostreedev/ostree/pull/2549https://github.com/flatpak/flatpak/issues/3479
This patch works around it by marking the commit we're about to pull
partial, so that if the .commit object exists in a staging directory
from a previous failed pull, it will not be erroneously considered a
complete commit, even by affected versions of libostree that don't have
the above patch. If for some reason the commit in the staging dir is
complete, libostree should harmlessly verify that and pull it in.
Usually the commit we are pulling does not already exist in the local
repo, but add a check anyway so we don't risk marking a complete commit
as partial, and so this works on the code path from
"flatpak install --reinstall ..."
Fixes#3479
(cherry picked from commit 11158c2481)
