Even though we are going to check all the `LC_*` environment variables,
if one of them is not set, we still need to consider LANGUAGE, LC_ALL
and LANG; there is no guarantee that *every* `LC_*` environment variable
is set (and in particular, during our build-time tests, they will usually
not be).
Resolves: https://github.com/flatpak/flatpak/issues/4471
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ae59fb7aca)
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)
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)
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>
These checks were broken in commit d762a2f, as the commit failed to
consider the fact that `flatpak_dir_check_parental_controls()` is run
both in the `flatpak` CLI process run by the user, but also in the
`flatpak-system-helper` process which always runs as root, and which
handles any installations done on the system repository.
As a result, parental controls were not working for the system
repository.
Fix that by limiting the scope of the check to only pass if running
without the system helper. flatpak calls from root never go through the
system helper.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #4418
In Yocto systems /var/tmp is a symlink to /var/volatile/tmp
because in its implementation of read-only rootfs /var is read-only
so /var/volatile is mounted as a tmpfs
and a subset of the paths point into it.
This would result in flatpak emitting mount arguments of
`--symlink ../var/volatile/tmp /var/tmp --bind /var/volatile/tmp /var/volatile/tmp`
which fails because flatpak has already added `--dir /var/tmp`
and the call to symlink fails with EEXIST.
This is fixed by blacklisting /var/tmp from symlink exports
in the same way /tmp is, so the bind is emitted as
`--bind /var/tmp /var/tmp`, which results in /var/volatile/tmp
being mounted into /var/tmp.
g_get_language_names() only returns the language names for the
LC_MESSAGES category, so mixed locale scenarios would result in missing
languages. Now, the languages are listed for each individual category.
Note that this issue was only present with the user installation. For
the system installation, the locales were queried from localed, and all
categories were checked.
In order to work on GLib versions < 2.58, the code to get language
names for a category has been backported.
Fixes#3712.
The Matrix room is just as public as the old IRC channel, which makes it
just as unsuitable for reporting security vulnerabilities as IRC.
Signed-off-by: Simon McVittie <smcv@collabora.com>
When flatpak-builder is running under flatpak, its
path will be /app/bin/flatpak. This path must not
be in export scripts or desktop file. This change
makes it possible for flatpak-builder flatpak to
tell flatpak what it should write to generated
files
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>
This takes them out of the directory that is "owned" by the subproject,
which will not be ignoring our Flatpak-specific generated files in
its .gitignore, and puts them in a directory that is "owned" by Flatpak,
which can ignore them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
