<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 31/12/13 05:02, Sebastian Wick wrote: <blockquote cite="mid:fe9aa65859f228a3cf1e13d1fa3eb436@sebastianwick.net" type="cite">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 </blockquote> 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 <a href="https://github.com/MaartenBaert/wayland-keylogger">proof-of-concept Wayland keylogger</a> 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. <blockquote cite="mid:fe9aa65859f228a3cf1e13d1fa3eb436@sebastianwick.net" type="cite">b) polkit authorizes the client </blockquote> 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 </body> </html>