On Tue, Jul 11, 2017 at 11:26:04PM -0500, mcatanzaro(a)gnome.org wrote:
But we have not been. Very few applications actually have SELinux
and they are all maintained downstream rather than upstream. The volume of
erroneous SELinux denials in Bugzilla is too high, and the response time for
fixing them too slow. SELinux profiles work best when they are maintained
upstream by application developers who are familiar with SELinux, not by
SELinux developers who are unfamiliar with the application.
We do have the same issue with sandbox policies for Flatpak, no? This
is the hard part of any sandboxing system and (judging from the current
docs) Flatpak hasn't tackled it yet.
A Flatpak app currently requires the following incantation to access the
host's dconf, so that it can behave like its users would expect:
Now, while this specific dconf issue might get solved at some point,
dconf won't be enough for the vast majority of useful apps. All the crap
that lives in the various dot files in your home directory and elsewhere
on the system and that affects the behaviour of a program needs to be
made available to the app. Other things must not be, such as everything
Some apps (e.g. virt-manager) need access to your ssh-agent socket but
you certainly don't want to make it available to every single app. This
is just a single instance of the general case of a program talking to
one of the numerous services that may run on the host.
programs depending on user configuration.
You want some environment variables passed through to the sandboxed app
(EDITOR or whatever) but not others (e.g. AWS_SECRET). How is the
Flatpak app even going to execute your favorite editor?
Someone is going to have to write all the policy for that. Otherwise,
the only apps that Flatpak will be able to handle properly are going to
be trivial mobile-style apps that don't interact with anything but their
developer's cloud services.