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
Make synopses more concise in various place, improve
consistency of formatting, and fix some small mistakes
and oversights.
Closes: #2307
Approved by: matthiasclasen
Mention how flatpak run handles environment variables,
and include the blacklist of variables we always override.
Closes: #2141
Approved by: alexlarsson
The --verbose and --ostree-verbose options are global to all
subcommands, but --version can only be used with the main "flatpak"
command, so fix the man pages to reflect that.
SSH authentication sockets can be placed in a number of places, so it
is difficult for applications to just mount a fixed directory or
directories, hoping that SSH_AUTH_SOCK points somewhere inside the
mounted content.
Closes: #1764
Approved by: alexlarsson
This gives access to AF_BLUETOOTH sockets in the seccomp rules. You additionally
need to give network access for the sockets to really work, because the
kernel doesn't (yet) namespace bluetooth sockets.
Closes: #1721
Approved by: alexlarsson
This means use x11 if no alternative is present, and should be used
for applications that support both X11 and wayland, but want to be
sandboxed when running under a wayland compositor (but still want to
run under an X server).
Closes: #1416
Approved by: alexlarsson
We need to know if we're forwarding uris or files, because
if we're doing uris we need to pass on non-file uris as-is.
So, we enclose uris with "@@u @@" instead.
This also properly (un)escapes the file uris
A few options aren't documented in the manpages. This commit adds
documentation for them based on the --help output and relevant commit
messages. Some of it could probably use more elaboration.
For a few commands the options aren't fully documented. This commit
makes the manpage documentation (almost) match the options shown
when you run "<command> --help" on the command line.
The ability to use flatpak-run to enter into a shell in a runtime was
added in flatpak 0.6.13 but the docs weren't updated to reflect that.
This commit updates the flatpak-run documentation to explain the
functionality.
This adds a new "multiarch" feature which allows bundling e.g. 32-bit
binaries to be run in a x86_64 environment. By default, the seccomp
filter is configured to allow only the native architecture. When the
"multiarch" feature is enabled, the filter will be configured to allow
running binaries of additional architectures supported. For x86_64, this
allows x86 32-bit binaries; and for Aarch64, allows 32-bit ARM binaries.
Application bundles can use the feature e.g. in order to ship 32-bit
binaries alongside with a mostly-64-bit application. This is particularly
interesting when for applications that might launch themselves prebuilt
programs for which 64-bit versions do not exist. For example, the Steam
application is available as a 64-bit executable, but some of the games
available are 32-bit only. A Flatpak bundle for the Steam application
with "multiarch" enabled is able launch the 32-bit games -- without the
feature enabled, the seccomp filter would prevent them from running.
Multiple-architecture support is enabled by adding the "multiarch" value
for the "features" key in the metadata file for a Flatpak:
[Context]
features=multiarch;
The corresponding "--allow=multiarch" command line option is supported
in "flatpak build-finish" as well.
This is no longer needed, as we don't hard-require systemd --user.
We keep the opion there, but hidden in order to be backwards compatible
with old code that used this.
This enables support for ptrace and perf for the app, similar
to what run -d manually gave you before. This is nice to be
able to package an app like gnome-software.
I don't think it makes sense to have to enable this for everything.
It should be safe in the sense that you can't ever do more than
the user can do anyway, and there is no way to use this to communicate
with the rest of the system because you can't read from it.
The worst this could ever cause is to overload the system, but the
sandbox doesn't protect against that in any other way anyway.
This gives the application full access to the host /dev. Obviously
this is not great in terms of sandboxing, but its nice for applications
that use flatpak mostly as a way to do distribution of the app.
Also, its not like the app has full access to anything, its still
limited to the access right of the user.
