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. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
