<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 03/01/14 00:12, Sebastian Wick wrote: </div> <blockquote cite="mid:c659a125932bcd6dcf2c8991292eccb6@sebastianwick.net" type="cite">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. </blockquote> 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 :). <div class="moz-cite-prefix">On 03/01/14 00:12, Sebastian Wick wrote: </div> <blockquote cite="mid:c659a125932bcd6dcf2c8991292eccb6@sebastianwick.net" type="cite"> 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. </blockquote> I know that, I just wanted to point out that this should be clearly documented, because it sounds like a mistake that developers could easily make (i.e. they whitelist the binary of their Qt app, not realizing that Qt adds its own command-line arguments that could easily be abused, while they should have whitelisted a minimal bash script that launches the Qt app with no command-line arguments). Maybe the INI file could have an option called 'allow-arguments' that defaults to false, to block the most obvious abuses and make app developers aware of the issue. <blockquote cite="mid:c659a125932bcd6dcf2c8991292eccb6@sebastianwick.net" type="cite"> 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. </blockquote> So far your protocol sounded secure, but I think this is where it breaks down. You're leaving the Wayland server open to a <a href="https://en.wikipedia.org/wiki/Confused_deputy_problem">confused deputy</a> attack, and also a <a href="https://en.wikipedia.org/wiki/Social_engineering_%28security%29">social engineering</a> attack. The confused deputy attack is possible because it is extremely hard for the Wayland compositor to verify that an application that wasn't launched by the compositor itself isn't being manipulated by being executed from an unsafe environment (LD_PRELOAD). You can blacklist the most obvious problems, but never all of them. Besides, blacklisting is the wrong approach, whitelisting is much more secure. The social engineering attack is possible because the user can't verify that the dialog actually corresponds to the action he/she requested. This is because polkit only identifies the action and not the caller. A malicious application can simply give itself a nice inconspicuous name like 'GNOME Screenshot Application', and all the user will ever see is 'GNOME Screenshot Application requests permission to take screenshots'. The average user won't find this suspicious and will probably allow it. Additionally it makes things worse by training the user to accept security dialogs all the time, and it <a href="http://ux.stackexchange.com/questions/24339/are-there-any-studies-of-users-getting-jaded-of-dialog-requests">has been shown</a> that many users will eventually accept these dialogs without even reading them because they are so common. I strongly believe that these dialogs should be kept to a minimum and only used for really important things, like formatting a hard disk. Not for trivial things like allowing an application to take a screenshot. Otherwise we will get the same problems that UAC has on Windows. <blockquote cite="mid:c659a125932bcd6dcf2c8991292eccb6@sebastianwick.net" type="cite"> Two reasons: 1. applications should not provide polkit rules </blockquote> My email was confusing, I meant polkit actions (/usr/share/polkit-1/actions). In some cases these are provided by the application. On my Arch install, GParted provides an action file to start GParted as root using pkexec (this is then used in the desktop file). <blockquote cite="mid:c659a125932bcd6dcf2c8991292eccb6@sebastianwick.net" type="cite">2. it still works without polkit, it's optional and just makes some stuff easier [...] Like I said, polkit makes stuff easier for the user - nothing else. </blockquote> These applications will have to be rewritten anyway to use Wayland protocols and this new authentication API, so how hard is it for the developers to write a 5-line INI file and put that in the right directory? Do you really want to add a second authentication API that adds potential security issues, just so developers don't have to write an INI file? I'm not criticizing the polkit authentication because it has no use, I just want to minimize the attack surface. Maarten Baert </body> </html>