Authorized clients

[Maarten Baert]

On 03/01/14 03:27, Sebastian Wick wrote:
> 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 understand that, but it doesn't really answer my question. Of course
you can always ask, it doesn't mean the compostor will accept it. So my
question is, when the compositor checks the authentication INI files to
decide whether the application being launched should get privileges,
does it do that based on the path of the application being launched, or
the path of the application that sent the request? Only the first method
is secure.

> Again, every client which wants to access restricted protocols has to
> be launched by the compositor and it doesn't use any blacklist.
Okay, that wasn't clear to me. This does prevent environment-based
attacks and that's great, but it doesn't solve the social engineering
problem.

> That kind of attack would work on every program which uses polkit but
> it's not the problem of the library users.
Exactly, but it is a problem for the users. That's why I want to avoid
needless polkit dialogs.

> If you think your users
> are confused by a password prompt you can configure polkit to simply
> deny all those authorization requests.
If Wayland offers polkit as a valid authentication method, then
applications will start to rely on that. If the user or the sysadmin
then disables these dialogs, it will break those applications. Both
users and sysadmins will likely choose convenience over security, and
that is a problem.

> 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.
Pkexec is an exception, it is designed to use actions files that are
provided by other applications. Pkexec is the authority here (it is
setuid, it decides what gets launched), and applications like gparted
provide an actions file so they can be launched as root by pkexec.

> 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.
Is this necessary? How many users need standalone applications that use
sensitive Wayland protocols on a machine where they do not have root
access? I suspect most sysadmins would prefer that the user is simply
not allowed to do that, it is a potential attack vector and doesn't add
enough value to justify the risk IMHO.

> I do understand that but I don't think that there is a big attack
> surface at all.
Take a look at the current situation on Android. Even the simplest
Android apps require ridiculous permissions, and most users just accept
them anyway, because they are so used to it! Even if Android was fully
secure, bug free and updated regularly, 90% of the Android phones would
still be horribly insecure because most people blindly accepts the
warning dialogs. It's easy to blame the users for doing stupid things,
but I think it is the responsibility of the developers of the
authentication mechanism to design the system in such a way that users
aren't encouraged to do stupid things.

Maarten Baert