Authorized clients

[Maarten Baert]

On 03/01/14 00:12, Sebastian Wick wrote:
> Maybe I should have made it more clear. The client must be started by
> the compositor and it needs permission from either a config file or
> polkit. The patches introduce a new protocol which lets a client tell
> the compositor to start a new program/client.
Okay, so the path in the config file is indeed the path to the
executable that will be launched by the Wayland compositor, and _not_
the path of the executable that /sends the request/ to launch a
(different) privileged executable, right? Just checking :).

On 03/01/14 00:12, Sebastian Wick wrote:
> That's not a problem as long as you don't allow bash to use a restricted
> protocol. If a program can do something you don't want it to do you
> shouldn't give it permission anyhow.
I know that, I just wanted to point out that this should be clearly
documented, because it sounds like a mistake that developers could
easily make (i.e. they whitelist the binary of their Qt app, not
realizing that Qt adds its own command-line arguments that could easily
be abused, while they should have whitelisted a minimal bash script that
launches the Qt app with no command-line arguments).

Maybe the INI file could have an option called 'allow-arguments' that
defaults to false, to block the most obvious abuses and make app
developers aware of the issue.

> They have a completely different purpose. The config files allow
> specific protocols for a specific executable. If a client wants to use
> more protocols than allowed in the config files or there is no config
> file at all, the client could not use any of the restricted protocols.
> In that case the compositor asks polkit if the process is allowed
> to use the protocol or not. Polkit is a system-wide configuration which
> means that you can make a restricted interface available for every
> client in case that you don't care about the security feature or make
> it ask for the user or admin password.
So far your protocol sounded secure, but I think this is where it breaks
down. You're leaving the Wayland server open to a confused deputy
<https://en.wikipedia.org/wiki/Confused_deputy_problem> attack, and also
a social engineering
<https://en.wikipedia.org/wiki/Social_engineering_%28security%29> attack.

The confused deputy attack is possible because it is extremely hard for
the Wayland compositor to verify that an application that wasn't
launched by the compositor itself isn't being manipulated by being
executed from an unsafe environment (LD_PRELOAD). You can blacklist the
most obvious problems, but never all of them. Besides, blacklisting is
the wrong approach, whitelisting is much more secure.

The social engineering attack is possible because the user can't verify
that the dialog actually corresponds to the action he/she requested.
This is because polkit only identifies the action and not the caller. A
malicious application can simply give itself a nice inconspicuous name
like 'GNOME Screenshot Application', and all the user will ever see is
'GNOME Screenshot Application requests permission to take screenshots'.
The average user won't find this suspicious and will probably allow it.

Additionally it makes things worse by training the user to accept
security dialogs all the time, and it has been shown
<http://ux.stackexchange.com/questions/24339/are-there-any-studies-of-users-getting-jaded-of-dialog-requests>
that many users will eventually accept these dialogs without even
reading them because they are so common. I strongly believe that these
dialogs should be kept to a minimum and only used for really important
things, like formatting a hard disk. Not for trivial things like
allowing an application to take a screenshot. Otherwise we will get the
same problems that UAC has on Windows.

> Two reasons:
> 1. applications should not provide polkit rules
My email was confusing, I meant polkit actions
(/usr/share/polkit-1/actions). In some cases these are provided by the
application. On my Arch install, GParted provides an action file to
start GParted as root using pkexec (this is then used in the desktop file).

> 2. it still works without polkit, it's optional and just makes some
>    stuff easier
> [...]
> Like I said, polkit makes stuff easier for the user - nothing else.
These applications will have to be rewritten anyway to use Wayland
protocols and this new authentication API, so how hard is it for the
developers to write a 5-line INI file and put that in the right
directory? Do you really want to add a second authentication API that
adds potential security issues, just so developers don't have to write
an INI file?

I'm not criticizing the polkit authentication because it has no use, I
just want to minimize the attack surface.

Maarten Baert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140103/0c4d92b7/attachment-0001.html>