Add '--usb' and '--nousb' to the FlatpakContext option group.
Map these parameters to either the enumarable list, or the hidden
list, of a new "USB Devices" group in the metadata key file. It looks
like this:
```
[USB Devices]
hidden-devices=cls:01:*;
enumerable-devices=vnd:0fd9+dev:0080;vnd:0fd9+dev:0080;
```
Flatpak itself does not use these values, they're meant to be used
by e.g. XDG Desktop Portal to filter which devices the app can see
through the USB portal.
Hidden devices must always take precedence over enumerable devices.
This is heavily inspired by https://github.com/flatpak/flatpak/pull/4083
Co-Authored-By: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
Co-Authored-By: Ryan Gonzalez <rymg19@gmail.com>
Signed-off-by: Hubert Figuière <hub@figuiere.net>
We now resolve the zoneinfo and always make it available at
/usr/share/zoneinfo in the sandbox so we unset TZDIR to get flatpak apps
looking at the right directory.
This adds a new `usb` device in the list to grant access to the whole
USB bus. This is narrower than `all` and should be enough for
anything accessing the USB directly (i.e. using libusb or equivalent).
This doesn't grant access to synthesized devices, i.e those exposed
in `/dev` but using USB, including but not limited to USB serial, webcams,
hidraw, hid, sound.
Close#4405
Signed-off-by: Hubert Figuière <hub@figuiere.net>
This option allows the application (or subsandbox) to own the specified
name on the a11y bus. This will be useful for WebKit, that has a strict
security need that the Web processes cannot talk or see each other.
An alternative approach would be to make xdg-dbus-proxy permissions
modifiable at runtime, but that seems a lot riskier than this. Owning
a well known name based on the app id has proven to be a robust and
secure approach after all.
Following on from b8d8d80c61, add more environment variables used by
the Vulkan loader which expect paths to be provided.
These paths are typically referencing the host filesystem; if the user
is referencing paths only available in the sandbox, they can use --env
or overrides for them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Similar to how b8d8d80c61 inhibited passthrough of environment
variables pointing the Vulkan loader towards a specific ICD, do the same
for the EGL paths used by libglvnd to discover the GL driver to use, as
well as for NVIDIA's EGLStream shim.
These paths are typically referencing the host filesystem; if the user
is referencing paths only available in the sandbox, they can use --env
or overrides for them.
Signed-off-by: Daniel Stone <daniels@collabora.com>
I don't think this env var makes much sense to pass into the sandbox
for similar reasons to LD_LIBRARY_PATH. Libraries from the host
just aren't relevant.
Users can still pass `--env=LD_PRELOAD=/foo` to use this functionality.
1. For security context creation, only relies on WAYLAND_DISPLAY, do not
use WAYLAND_SOCKET since the file descriptor defined by WAYLAND_SOCKET
can be only consumed once.
2. Due to the incompatiblity between WAYLAND_SOCKET and the security
context, add a new permission --socket=inherit-wayland-socket
to limit the usage of WAYLAND_SOCKET to an opt-in feature. Only when
this flag is set, WAYLAND_SOCKET will be passed to the sandbox.
3. When WAYLAND_SOCKET is not inherited, set FD_CLOEXEC to avoid it to
be leaked the to sandbox.
Closes: #5614
These environment variables inform the Vulkan loader on where to find driver files.
Since they typically point to locations on the host filesystem, any application that
attempts to load Vulkan within the flatpak sandbox would break with these set.
If the `GDK_BACKEND` environment variable is present and it's value does
not match the Wayland and X11 socket configuration, then a GTK app will
fail to run since it will only consider the display backend from the
environment variable.
This should probably be extended to cover other display environment
variables such as `QT_QPA_PLATFORM` for Qt and `SDL_VIDEODRIVER` for
SDL. However, I've only tested this with GTK applications.
This variable contains paths to load GIO modules from. For the most
part, they refer to paths outside of the sandbox or if they happen
to be in the sandbox, would contain modules that are incompatible with
the sandbox runtime (ie. different libc).
While I've not found programs that would crash outright, it may cause
unexpected behaviors (eg. Apostrophe not being able to render math in
preview panel).
This variable is set by NixOS for its dependency boxing.
This variable is typically used to configure the use of a custom
set of XKB definitions. In those cases, it's mostly meant for the
X11 server or Wayland compositor. NixOS is known to employ this
variable for their custom XKB layout implementation.
When the path it points to is unreachable (due to the sandbox),
most GTK+/Qt applications will crash on Wayland.
Unsetting this does not seem to negatively impact the use of custom
XKB layouts with Flatpak applications.
If this environment variable is set on the host, it's going to mess up
authentication in the sandbox. For example, if the host has:
KRB5CCNAME=KCM:
then the sandboxed process will try to use the host KCM socket, which is
not available in the sandboxed environment, rather than the gssproxy
socket that we want it to use. We need to unset it to ensure that
whatever configuration we ship in the runtime gets used instead. We have
switched the GNOME runtime to use an empty krb5.conf and it works as
long as we don't break it with this environment variable meant for the
host.
Save folks a few keystrokes. There is a command which already has a '-u'
option, document-export, but it doesn't support --user so there should
be no conflict. However '-s' is used by the info command among others,
so we can't use that for --system.
We already allow normal apps to own MPRIS names but subsandboxes could not.
This allows them with the same dbus restrictions that they must be
prefixed by $app_id.Sandboxed.
This will be used by WebKitGTK.
This reintroduces the special case that existed in Flatpak 1.12.3, but
under a different name, so that it will be backwards-compatible. With
this change, flatpak-builder will be able to resolve CVE-2022-21682 by
using --filesystem=host:reset.
We want to implement this as a suffix rather than as a new keyword,
because unknown suffixes are ignored with a warning, rather than causing
a fatal error. This means that the new version of flatpak-builder will
be able to run against older versions of flatpak: it will still be
vulnerable to CVE-2022-21682 in that situation, but at least it will run.
Co-authored-by: Alexander Larsson <alexl@redhat.com>
There are two reasonable interpretations for --nofilesystem=home:
either it revokes a previous --filesystem=home (as in Flatpak 1.12.2 and
older versions), or it completely forbids access to the home directory
(as in Flatpak 1.12.3). Clarify the man pages to indicate that it only
revokes a previous --filesystem=home. This will hopefully reduce
mismatches between the design and what users expect to happen, as
in flatpak#4654.
A subsequent commit will introduce a way to get the Flatpak 1.12.3
behaviour in a way that is more backwards-compatible with Flatpak 1.12.2
and older versions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The new behaviour caused regressions in some situations that previously
worked, and will be reverted.
This reverts commit 4d11f77aa7.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This gives new support for the new XDG_STATE_HOME addition to XDG_BASE_DIRS
which allows applications to use this without breaking because they would
assume $HOME/.local/state which may be unavailable to the flatpak
This adds it as .local/state as to make --persist=.local/state the same behaviour
as in new flatpak. This in turn means that the transition should be seamless between
old and new flatpak.
This also has the benefit of working if the application doesn't follow XDG spec thanks
to --persist=.local/state.
This fixes https://github.com/flatpak/flatpak/issues/4477
[smcv: Don't call nonexistent g_get_user_state_dir(); fix a reference
to XDG_STATE_DIR]
The pressure-vessel container tool in Steam will want to use this, to
replace /usr with a Steam Runtime container supplied by the Steam CDN,
instead of using the same Flatpak runtime that is used to run the Steam
client and non-containerized games.
If a custom /usr is used, the "official" Flatpak runtime is still the
one reflected in the metadata. It is also mounted at /run/parent,
with all its extensions, so that pressure-vessel has the option of using
its graphics drivers (by populating the custom /usr with symlinks into
/run/parent and/or /run/host).
When doing this, we need to put an empty directory on /app, because
the real /app expects to be run on top of the real runtime. It would
also be reasonable to substitute a custom replacement for /app, so
I've included support for that too.
Partially addresses #3797.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This follows up from GHSA-4ppf-fxf6-vxg2 to fix missing functionality
that I noticed while resolving that vulnerability, but is not required
for fixing the vulnerability.
Signed-off-by: Simon McVittie <smcv@collabora.com>
As with flatpak run --parent-expose-pids, this will only work if we have
a working, non-setuid bwrap. Systems where user namespace creation is
restricted and bwrap needs to be setuid (Debian 10, RHEL/CentOS 7,
Arch Linux linux-hardened kernel) will have degraded functionality.
This option is similar to --expose-pids, except that instead of making
the subsandbox use a nested pid namespace inside the parent's, it makes
the subsandbox share the parent's pid namespace as-is, so that process
IDs in the parent and the subsandbox are interchangeable. This will
be useful if the parent and the subsandbox communicate via protocols
that assume a global view of the process ID namespace, for example
passing process IDs across an AF_UNIX socket or in shared memory.
In particular, this will be useful for Steam's pressure-vessel container
tool: the IPC between the Steam client and the "game overlay" loaded into
Steam games uses process IDs, and becomes confused if they don't match up.
This weakens the security boundary between a subsandbox and the parent,
but that's OK in some cases, especially if the subsandbox is being used
as a way to get a different runtime /usr (flatpak-spawn --latest-version
or #4018) rather than as a security boundary.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, there were three different DTDs used. Let's switch to a single one.
We will go with 4.5, since it is latest version that does not have any backwards incompatible changes.
The terms whitelist and blacklist are hurtful to some people, and per
our code of conduct Flatpak is an inclusive community. Replace them with
allowlist and blocklist which are also more clear. This terminology
change is being implemented more broadly in the software industry; see
e.g. https://go-review.googlesource.com/c/go/+/236857/
These are subsets of the host keyword, which provide access to operating
system files but not to users' personal files.
In particular, the experimental support for namespace-based sandboxes
in the Steam Runtime[1] uses the graphics stack from the host system,
which requires access to the host /usr/libQUAL, /libQUAL (even if the
host OS has undergone the /usr merge, the canonical paths of ELF
interpreters start with /lib), /etc/ld.so.cache, and for some libraries
on Debian-based systems, /etc/alternatives. It will not be possible to
do similar things in Flatpak without either allowing full host
filesystem access (which exposes personal files, and in any case cannot
be done by the Steam app because it is incompatible with --persist=.),
or adding the ability to expose /usr and related directories without
including the rest of the host filesystem.
To the best of my knowledge, host-etc is not necessary for anything;
I've mainly provided it for symmetry, since it's the other significant
thing that we mount in /run/host and cannot get via --filesystem=/path.
Some notes on the security/privacy implications of the new keywords:
- Neither new keyword allows anything that was not already allowed
by "host".
- Neither new keyword can allow anything that was not already allowed
to the user outside the sandbox.
- "host-os" allows enumeration of the installed packages on the host
system, and often their version numbers too. A malicious app could
use this to look for exploitable security vulnerabilities on the
host system. An app could also use this for fingerprinting, although
this is not a regression, because the systemd/D-Bus machine ID,
MAC addresses, hostname, kernel boot UUID, DMI product ID and many
other unique or relatively unique properties are already available
inside the sandbox.
- "host-os" allows read access, and possibly write access (if the user
has it outside the sandbox, for example members of group 'staff' in
older Debian installations), to /usr/local.
- "host-etc" allows reading configuration files whose contents might
be considered sensitive, such as /etc/passwd.
[1] https://steamcommunity.com/app/221410/discussions/0/1638675549018366706/
Signed-off-by: Simon McVittie <smcv@collabora.com>
This new permission exposes the host /dev, which is normally not visible
even with --device=all, as it is not really a device node but rather
a bunch of shared memory blocks available on the host.
This access is needed by jack, as explained at:
https://github.com/flatpak/flatpak/issues/1509
Long term I think a better solution for pro audio (like pipewire) is
a better solution, but for now we should at least allow jack apps to work.
Prevent the user from running a flatpak app if that app is filtered by
the parental controls applied to the user.
If flatpak is running as a system user (UID < 1000), ignore failure to
load the app filter. This could happen if a flatpak is run in the
gnome-initial-setup session, before the user’s account is created.
Includes contributions by André Magalhães.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://github.com/flatpak/flatpak/pull/2797
