Authorized clients

[Sebastian Wick]

Am 2014-01-02 23:01, schrieb Maarten Baert:
> On 31/12/13 05:02, Sebastian Wick wrote:
>  I haven't looked at your code yet, but I suspect this detection
> mechanism would be seriously flawed, because it doesn't consider the
> environment of the application (chroot, LD_PRELOAD, LD_LIBRARY_PATH,
> the Qt and GTK plugin mechanisms are also triggered by environment
> variables and allow loading arbitrary code). My proof-of-concept
> Wayland keylogger [1] demonstrates that: it's not limited to logging
> keys, it can do anything at all, including accessing sensitive Wayland
> APIs if the original application is allowed to do that.

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.

>  By the way, the executable path alone is not enough, because
> applications launched with different command-line arguments can behave
> very differently, even if the environment is completely clean. This
> can be solved by launching a simple bash script rather than the actual
> application, and letting that script decide what arguments are allowed
> (the simplest case would be a bash script that ignores all arguments
> and just launches the application). That's something application
> developers should be made aware of.

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.

>  Correct me if I'm wrong, but my understanding was that polkit
> authorizes _actions_, not clients. It doesn't seem to care what
> application requested the action, it just asks the user 'do you want
> to execute this action?' and the user decides. In this case, the
> action is launching an application with access to sensitive Wayland
> APIs, regardless of what application requested that action. Again, to
> me this seems like the only safe way to do this - just because the
> client is a known program doesn't mean that it can be trusted.

Authorization for an action is always bound to a subject; in this case
to a process.

>  I don't really understand why you want to use custom configuration
> files _and_ polkit, which has pretty much the exact same purpose. Why?

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.

> If Wayland is going to use polkit for the authentication API, why are
> the Wayland-specific authentication rules even needed? Polkit already
> has an advanced rule system, it would be easy enough to just add the
> executable path and the list of allowed protocols to the polkit
> actions file, right? This seems to be what 'pkexec' does (the polkit
> equivalent of sudo/gksudo/kdesu).

Two reasons:
1. applications should not provide polkit rules
2. it still works without polkit, it's optional and just makes some
    stuff easier

>  Adding two parallel authentication mechanisms with the same purpose
> doubles the attack surface, and I don't see the benefit. I'm not
> saying that we should use polkit, but I think there should be only one
> mechanism, not two.

Like I said, polkit makes stuff easier for the user - nothing else.

>  Is it acceptable for the Wayland protocol to have polkit as a
> dependency for the authentication API?

It's a patch for weston, the compositor and it's an optional dependency.