Authorized clients

[Maarten Baert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 04/01/14 11:01, Martin Graesslin wrote:
> I will try to share my thoughts so far and I must say that I don't know whether that's implementable at
all. Of course we also thought about working with full paths, but I
don't think that's a good solution for a flexible desktop environment
such as Plasma.
Only the initial application needs a configuration file with a full
path. As far as I understand, this application could simply be a stub
that executes the real application. The responsibility is then moved to
the stub to decide whether an application (such as a Plasma widget, I
suppose) can be trusted. This means all the complexity doesn't need to
be built into the compositor.

> Also it creates a terrible linear chain in the startup - we want to move to a more flexible
framework and don't turn KWin into another system startup process. It
might be a solution for things like KSnapshot but certainly not to bring
up the desktop shell.
In the proposed design, the compositor only launches applications after
being told to do so by other applications. So KWin wouldn't be the
startup process, it would simply act as a proxy - much like klauncher,
actually.

> The idea I have so far is to depend on cgroups and namespaces. Thus everything which needs the more
privileged interfaces needs to be in the "desktop shell" cgroup. I hope
that we can make use of systemd to provide us such features. Clients
which are not in the trusted group will not get the more exposed interfaces.
It would be a powerful solution, but it would make Wayland depend on
systemd and Linux-specific features.

> This could also work for things like screenshooters, but here we start to enter trust issues again. We
certainly would trust a KDE application, but that's already quite
borderline. For such cases so far I only have the idea of nag screens
like UAC. I hate that and absolutely don't want to implement it. So I'm
looking forward for good solutions. Polkit could be a nice solution to that.
Only if polkit is configured with enough action files to whitelist
specific applications, and at that point you end up with pretty much the
same configuration file system that was proposed originally. Polkit
without proper configuration would be no better than UAC.

> I'm not so sure about configuration files as I don't believe in whitelists in general :-)
Obviously it allows the distribution to properly setup the system but
there might be better solutions to that. My suggestion here is to
specify the interfaces in the desktop file.
It would not be a global whitelist maintained by the sysadmin, it would
be a bunch of config files installed by the applications themselves
(assuming applications are installed by root, which to me seems like a
reasonable assumption because that's what all the package managers do).

I don't think specifying interfaces in the desktop file is any different
from specifying them in a Wayland-specific config file, but I think it
will complicate things.

It will mean that many desktop files will have to be rewritten: you
can't specify a Qt binary as the application, because Qt has a number of
command-line arguments that can be abused. As I said a few mails back,
the application would have to be a stub (e.g. a simple bash script) that
filters the command-line arguments and only allows those that are safe.

Additionally, if the interfaces are defined in the desktop file, then
any application that uses desktop files (AFAIK that includes
applications like Firefox, and of course various desktops, panels,
widgets, launchers etc.) would have to be Wayland-aware and launch
applications that need more privileges through the Wayland compositor
rather than the normal way.

And there's another problem: Most desktop environments allow you to put
desktop files on the desktop. Not links to desktop files, but actual
copies of the desktop file. The user can simply modify the desktop file
and allow any interface he wants - and so can a malicious program. It
could be argued that copying desktop files was a bad idea in the first
place, but this is how things are currently being done.

However, if we keep the desktop files and Wayland config files
separately, then the desktop file can point to a bash script that will
execute the application through the Wayland compositor. This keeps
launching desktop files simple.

In my opinion desktop files and Wayland config files have a very
different purpose. The desktop files are there for convenience, they are
simply shortcuts for common actions that would otherwise require a
terminal. The Wayland config files OTOH are a security feature. I don't
think the two should be mixed.

Maarten Baert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSyDsrAAoJEAeyXy8uXJOQchwP/A1eqdfjg8jBhfx3KLiMzg5Z
otKO8U7QEHBVsdf68eu9zicaG5LwA7cszyjI4zEiNyBwMUgbM2VyHp33kr/D+c0X
6vApG4KHAxo1zDFR0Xp3MVGaTBRFLV3lEO9yxXukHARtS6jMfUhx729XpWGfcmPd
KMNFoxYtmSKfeWZ/lJzGYQC+QNSa6hTsYWcfjW9k5FPwsgE5nEs7JkZwwEQ0VnE7
fR1Se4hrCwkiLvVYOKiaA7w2dBjmd9tCZrDODuIbPe4TNUt0jsrMv/9eiUcMdveS
/oNEL2QgLLQzKzbOGi195IlrudCDSFLbSmw/kV9l9owg+X1tKLAQOz9X6R1WDe+F
eqjZeIGAHofxOASlpZVXc1x9YaS3jk/U7s6LnWe08hCMOseoZUuzufOVgzEDPKuj
1Xvbx4nzaasngW4Cu3mIriOx1BJmXyJCKzcYN4F4OV715R+niRoGP/5RXFbrHynX
JPpElwZ9pJYSXVobRCMYMSlXel9KI1eSIAVu0rr0eu+LrXJZzKeEGN5C/yvX4ptO
Opg5tpIABGPe4KgI6nLM5rzHu8rpgERC56nTDuDlaGa8KZNTBoLRaoV0otG2ggA2
x7cGmpeEHTwkOQ0cykjLscUSsQZVNLbkwi6IzdWiuOSXVZWwzQq+1aSMzPB58jd8
HpguioqSpotOXbW/IkdP
=Kuvc
-----END PGP SIGNATURE-----