Authorized clients

[Sebastian Wick]

Am 2014-01-03 02:19, schrieb Maarten Baert:
>  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 :).

Any client can tell the compositor to launch any executable.

>  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.

There is nothing we can do on a technical level so that sounds fine.

>  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 [1] attack, and also a social engineering [2] 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.

Again, every client which wants to access restricted protocols has to
be launched by the compositor and it doesn't use any blacklist.

>  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 [3] 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.

That kind of attack would work on every program which uses polkit but
it's not the problem of the library users. If you think your users
are confused by a password prompt you can configure polkit to simply
deny all those authorization requests.

>  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).

Those files are provided by the authority which is weston in this case.
It would be possible to pass arguments to polkit and let the programs
provide .rules files.

>  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?

It's about standalone applications which you don't install. They still
have to work and that's not possible when using config files only.

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

I do understand that but I don't think that there is a big attack
surface at all.