Authorized clients

[Maarten Baert]

On 31/12/13 05:02, Sebastian Wick wrote:
> A client is authorized for a protocol if...
> a) the client's executable path is found in a config file in the
> directory
> /etc/xdg/wayland/auth.d and if the config allows access on the protocol
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
<https://github.com/MaartenBaert/wayland-keylogger> 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.

But clearly you are already aware of this problem, because you proposed
that the compositor launches the application to maintain a chain of
trust (a good idea). So why don't you just use the path of the
_application being launched_ rather than the current client (i.e. like I
proposed in one of my previous mails)? To me this seems the only secure
way to do this.

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.

> b) polkit authorizes the client
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.

I don't really understand why you want to use custom configuration files
/and/ polkit, which has pretty much the exact same purpose. Why? 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).

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.

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

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