Use the user’s OARS filter to prevent installation or upgrade of
apps which have more extreme content than the user is allowed to see.
This uses libmalcontent to load the user’s enforced OARS filter, which
describes the extremeness of each type of content the user is allowed to
see. If an app they are trying to install exceeds the filter value in
any OARS section, installation is disallowed and an error is returned.
libmalcontent stores the parental controls policy per-user in
accountsservice, which enforces access control on the policies.
The app filter is also allowed to prevent app installation entirely,
which overrides the OARS values. This is independent from the app-install
polkit action, which determines whether an unprivileged user may install
an app system-wide. Being stored in accountsservice, the new boolean is
also easier to set per-user without having to programmatically write a
polkit JS policy file which handles multiple users (and parse it back
again).
The parental controls checks are done at deploy time, either in the
`flatpak` process (for user repositories) or in the
`flatpak-system-helper` (for system repositories). The checks use
content rating data extracted from the app’s AppData XML and stored in
the `FlatpakDeploy` cache. The checks are passed through polkit (even
for user repositories) so that users can get an admin override to
install apps which would otherwise be too extreme. This uses the new
`org.freedesktop.Flatpak.parental-controls` polkit rule.
The checks have to be done at deploy time, as that’s when the AppData
XML for the app is parsed. The downside of this arrangement is that an
app must be entirely downloaded before the parental checks can be done.
This won’t be much of an issue on normal desktops, however, since we can
assume that gnome-software will check an app’s appropriateness before
showing it to the user in the first place.
Parental controls are not enforced for non-apps/runtimes, which includes
the ostree-metadata and appstream/* refs.
One thorny issue is that flatpak unit tests may be run in an environment
with no system D-Bus available to connect to (a Jenkins instance, for
example), which means the call to `mct_manager_get_app_filter()` in
`flatpak_dir_check_parental_controls()` fails.
So this commit skips the parental controls check if the system bus is
unavailable and the environment variable
`FLATPAK_SYSTEM_HELPER_ON_SESSION` is set, since the testlibrary already
sets that variable so that the system-helper will be started on the
session bus.
The feature can be tested using something like:
```
$ malcontent-client set philip \
violence-realistic=none app/org.freedesktop.Bustle/x86_64/stable
App filter for user 1000 set
$ flatpak run org.freedesktop.Bustle
error: Running app/org.freedesktop.Bustle/x86_64/stable is not allowed by the policy set by your administrator
$ flatpak --user install flathub io.github.FreeDM
error: Failed to install io.github.FreeDM: Installing app/io.github.FreeDM/x86_64/stable is not allowed by the policy set by your administrator
```
Includes work by André Magalhães and Umang Jain.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
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
Also sort CFLAGS alphabetically. This will reduce the likelihood of
merge conflicts in future. This assumes the libraries and CFLAGS are
independent of each other.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The org.freedesktop.Flatpak user D-Bus service isn't just used by
flatpak(1) or applications running as Flatpaks. It's also used by
toolbox(1) for similar reasons:
* To keep various configuration files inside the container
synchronized with the host
* To let the container request certain commands to be run on the host
The org.freedesktop.Flatpak D-Bus service itself doesn't need much in
the way of dependencies, but inherits a lot of unused shared library
linkages through the libflatpak-common.la convenience library. Removing
these unused shared libraries reduces the footprint of toolbox(1) for
those who care about such things. eg., Fedora CoreOS.
This commit brings down the number of shared libraries to 19 from 62.
Closes: #3052
Approved by: alexlarsson
The libxml API is used in a relatively few places inside the 'common'
sub-directory. It's definitely not as widespread as GLib. A subsequent
commit will leverage this to prevent unused shared libraries from
being linked to the session helper.
Closes: #3052
Approved by: alexlarsson
The libarchive API is used in a relatively few places inside the
'common' sub-directory. It's definitely not as widespread as GLib. A
subsequent commit will leverage this to prevent unused shared
libraries from being linked to the session helper.
Closes: #3052
Approved by: alexlarsson
In the normal case, pass the full LIBEXEC path, and in the tests,
pass the path via the env var FLATPAK_REVOKEFS_FUSE.
Closes: #2657
Approved by: alexlarsson
We want to move away from using dconf inside the sandbox,
and instead use the keyfile backend for GSettings, which
has gained the capability to read defaults and locks.
This change makes the dconf database contents and locks
available in a suitable format. The files appear inside
the sandbox in the /etc/glib-2.0/settings directory.
We only export the default values for keys in the dconf
subtree whose path matches the app id, as well as prefixes
listed in paths key from the X-DConf group in metadata.
This commit adds a new dependency, since we're now linking
against libdconf.
Closes: #2295
Approved by: alexlarsson
We no longer use it here. flatpak itself still links
against it. This avoids problems with consumers who
might also link against libappstream.
Closes: #2580
Approved by: alexlarsson
This is currently only used in the ‘search’ built-in command, but will
need to be used in upcoming parental controls filtering changes in
Endless OS (which will go upstream eventually) too.
This introduces no functional changes.
The CFLAGS/LIBADD changes are necessary because of the new
AppStream #includes.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Closes: #2296
Approved by: matthiasclasen
Write to the systemd journal for basic operations
that modify installations, such as pull, deploy,
uninstall. Include some useful information as
separate fields, such as OPERATION, INSTALLATION,
REMOTE, REF, COMMIT.
We add the logging in the api layer that is used
by the system-helper as well, so that changes
from that side are logged as well.
All logs we write currently use the same message
ID, defined as FLATPAK_MESSAGE_ID in the headers,
for easy retrieval of messages.
This is made to let gnome-software enumerate all
running instances and get the same information
about them that flatpak ps provides.
For now, we keep it private. It will become library
api once we open new development
In preparation for extending the HTTP downloading function to include
caching, split HTTP related utilities into a separate file with a
separate header.
Closes: #1910
Approved by: alexlarsson
We forgot to include the sources. Also, we rename the valgrind header
to -private to avoid gtk-doc blowing its mind trying to parse it.
Closes: #1729
Approved by: alexlarsson
As per https://bugs.kde.org/show_bug.cgi?id=361770, this is not supported
by valgrind. We just don't seal the fds when debugging, this won't
affect anything at runtime in the normal case.
Closes: #1720
Approved by: alexlarsson
This moves all the files from lib into common, and it also adds all the libflatpak
sources into libflatpak-common, making libflatpak just a wrapper around the common
helper library.
This move allows the CLI to use all the code from libflatpak. We were already doing
this with a few things like flatpak-error*.[ch], and we want to do it even more
when sharing FlatpakTransaction. This also allows use to slowly move
the CLI to using the libflatpak apis for some things.
Closes: #1706
Approved by: alexlarsson
A symbol from this (flatpak_portal_error_quark) was leaked to libflatpak
due to being marked FLATPAK_EXTERN, so to keep ABI we move it back.
Fixes https://github.com/flatpak/flatpak/issues/1613Closes: #1616
Approved by: alexlarsson
This listens to org.freedesktop.portal.Flatpak and lets flatpak
sandboxes do flatpak specific things.
Initially this only allows access to "Spawn", which lets you start a
new copy of the current or latest version of the calling app,
optionally with sandboxing.
This allows the app to re-start itself with the latest version after
an update, and the sandboxing is useful for apps that want to manually
sandbox part of themselves.
You can also expose one or more subdirectories of
~/.var/app/$appid/sandbox/ to the app, read-write or read-only. This is
useful to communicate with the sandbox.
This is now in xdg-desktop-portal. We keep a version of the document
portal dbus XML so that we avoid weird build dependencies.
Flatpak itself is technically not dependent on the document portal,
but it is very much recommended that you use it.
Closes: #1398
Approved by: alexlarsson
For example, add $(AM_CFLAGS) to mumble_CFLAGS. Since $(WARN_CFLAGS) is
only added to $(AM_CFLAGS), this fixes the lack of inclusion of the
compiler warning flags in the compilation of half of flatpak.
Note that $(AM_*) variables are only used by automake if a more specific
(per-target) special variable is not defined instead. So if you define
mumble_CFLAGS, AM_CFLAGS will not be used for that target unless
explicitly included in mumble_CFLAGS.
See
https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html.
Do the same for $(AM_LIBADD), $(AM_LDFLAGS), etc. These are not
currently defined, but it’s good practice to include them in
mumble_LIBADD (etc.) just in case they’re defined in future. Hopefully
their inclusions will be cargo-culted to any new targets which are
added, retaining full coverage of the code base.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Changes to the Makefile could include changes to the options passed
to gdbus-codegen, which would invalidate the output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A rule of the form
foo.c foo.h: foo.in
some-generator --output=foo foo.in
is essentially equivalent to writing the same rule once for each target:
foo.c: foo.in
some-generator --output=foo foo.in
foo.h: foo.in
some-generator --output=foo foo.in
In a parallel build, this can result in some-generator being run more
than once with the same inputs and outputs, leading to unpredictable
results if the outputs are overwritten in-place by two parallel copies
(particularly if the generator does not use the standard atomic-writing
trick of writing out a temporary file and renaming it over the top of
the intended name, which gdbus-codegen does not).
gdbus-codegen happens to write the .h file before the .c file, so
use the real build rules to generate the .c file, and consider the
.h file to be a side-effect.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a pretty standalone object, and it is nicer to
have it in its own files. All users have been updated
to include the new flatpak-table-printer.h header.
If flatpak is built from a separate build directory, code generation
fails because the directory structure is not in place. Create the
necessary directories before code generation.
Bubblewrap is a new tool from project atomic. Its similar to the old
xdg-app-helper, but even more minimal, and a bit more generic. Its designed
to be easy to git submodule install, but at some point we will probably
support using the system installed version too.
Using bubblewraps lets us share the load of security mainainance and
allows other people to use bubblewrap to do their own unprivileged
sandboxes.
This avoids exporting glnx_*, calc_sizes(), etc. However, we do want to
export xdg_app_error_quark(), so do that.
Signed-off-by: Simon McVittie <smcv@debian.org>
We now check at runtime if we have raised privs, and only if not so do we try
to use unprivileged user namespaces. This means you can build xdg-app however,
and then setuid/setcap the binary however you want afterwards.
