<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">Le 08/01/2014 21:20, Sebastian Wick a écrit : </div> <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite">Am 2014-01-08 19:53, schrieb Martin Peres: <blockquote type="cite">Le 08/01/2014 17:20, Sebastian Wick a écrit : <blockquote type="cite">Am 2014-01-07 15:07, schrieb Martin Peres: <blockquote type="cite">Those are extremely rare cases. Users wanting to do that should agree they give up confidentiality and should thus be administrators in order to tell the compositor that. </blockquote> Why should those people have worse security then others only because they want a feature you define as non-standard? </blockquote> That's not what I meant. I meant that if they want what you say you want to allow, they will de-facto loose some security (namely, confidentiality if the screenshot app is misbehaving). </blockquote> I don't understand you. You trust the compositor to do the right things, why shouldn't you trust a screenshot app to do the right things? I mean, if you make a screenshot via a key-binding you also trust weston-screenshooter to not screw up. You have to trust the application if you want to give it access to a privileged protocol. </blockquote> The compositor has to be trusted. It has access to all the application's output buffer. What we want is to avoid other apps from getting them unless that's what the user intended to. This intent can be known by the compositor through the input devices. We don't need to trust the client much if we limit the number of screenshots to 1. This way, the worse thing that could happen for your privacy would be if your cat sits on the keyboard and presses "print screen" all the time while you key in sensitive information (unlikely, right?), even if the app just When you trust an application to always do the right thing, it can abuse its power in the user's back and I don't like that. <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite">In this case, we can still restrict access to the interface to a handful of programs to lower the risks, but it will still be possible for these applications to spy on the user without him knowing and this is something that shouldn't be allowed by default. </blockquote> Like I said, we should be able to let polkit decide. You could even distribute a .rules file which white-lists an application if we pass the executable path. </blockquote> It is indeed something that is good, but insufficient because the trusted programs can do whatever they want and the compositor won't be able to tell if what they request really is what the user wants. </blockquote> Of course they can. Every client can do whatever they want. Even when taking a screenshot in weston via a key-binding you launch weston-screnshooter and it can do whatever it wants to do. The only way to be sure that it does exactly what you want it to do is by reading the source code. </blockquote> This is not true. The server can refuse to feed the application with more than one screenshot. This severely restricts the possibilities of using this feature to spy on what a user is doing. <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite"> <blockquote type="cite">Simple example, you want a CLI application to be able to make screenshots and save them to a file. As an attacker, if I want a screenshot, I'll just run the program and get the screenshot. Is that something you think is OK, I definitely think this is not. </blockquote> It's not okay. You should not give the application permission to use the screenshoter protocol without further restrictions, then. If we would use polkit you could configure it so that the application gets access to the restricted protocol if it is started with root permission or after you entered your password. </blockquote> The only way I could possibly agree with you on this would be to have authentication on every call to the screenshot API with the following parameters: 1) full path of the app requesting that (if we can make sure of it when it has not been started by the compositor) 2) number of screenshots since the last time the "Print screen" event happened It seems 1) is doable ( <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <a href="http://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket">http://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket</a>) and 2) should be doable. However, I don't like the idea of having to audit the policy on every wayland computer I will be on especially since I'm pretty sure some devs won't mind if their application is a privacy killer. <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite"> Oh, and if you make a screenshot, no matter how, and save it to disk, it is readable by any other application you start. It's not our job to prevent that. </blockquote> I agree with that. Hence why we should limit the amount an app can make without user interaction. <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite"> <blockquote type="cite">This is why I said the compositor shouldn't agree on a screenshot request if it can't tell if it was a user-made request or an app-made one. </blockquote> That's wrong. It should not matter who made the request. If you can use a program to exploit the security, the program is broken or has the wrong security settings. </blockquote> I want to make sure you understand the concept of indirect interactions. If program A cannot access the screenshot API but program B can and program B can be made to save the file automatically without the user knowing, then program A can call program B and get whatever he wanted (I never trust a screenshot app to do the right thing). Is program B buggy or illegitimate? No, it does exactly what the user wants and is fine on its own. Does it trash the graphics output confidentiality of the whole computer? Yes! What if I use a computer and someone installed such an app (shared computer, for instance)? Well, I won't know I lost the confidentiality. Too bad.... This is why we need the user's input, either a run-time enable as Pekka suggested or a hot key one as I suggest. Both can be implemented if needed, they cover different use cases. <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite"> If you have a screenshot UI and it gets started (by whoever) the user must do something for the application to actually take the screenshot, otherwise it's broken. If you have a command line app to make screenshots and someone or something wants to start it there must be some kind of user interaction to confirm it. </blockquote> I fully agree here but contrarily to you, I don't want to trust the application. Anyway, glad to see we are on almost the same page ;) <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite"> If you press a key-biding and the compositor starts an application to make a screenshot there doesn't need to be a confirmation. We simply start the app and be done with it. </blockquote> Yes, but only a physical user can press this key. This is like pressing a button on the screen with a mouse. <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite"> So we can have a configuration which only allows access to restricted protocols if the user agrees to it (or something else, this is really up to the one who configures the system). If the request to start the application comes from the compositor itself we can safely assume that everything is fine and start to app. If the request to start the application comes from another client, we check the configuration. If the configuration says it's fine to start the app, we do so (however it will determine if it's okay or not; maybe the app is configured to just start, maybe the app is configured to require the user to press on a "yes" button, maybe the app is configured to require the user to enter his password or maybe it is simply configured to deny the request). </blockquote> Yep, that would be a good fallback but as I said before, if someone installs such an app on my computer and it can do screen captures without my interaction, then I just lost the confidentiality of my desktop. I just don't like the concept of not further checking how the app is using the interface. <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite"> <blockquote type="cite">The only solutions we found so far have been: - listen for hot keys from an input device (we have to trust the kernel for not allowing to forge events) - require a confirmation of some sort (popup / systray icon / whatever) </blockquote> Like I said, we can configure certain application to not require a confirmation dialog. <blockquote type="cite">The decision making is just what it is, a decision. This is an implementation detail. You propose to use polkit for the decision making, why not? But I think this is overkill since we only need a file in /etc/wayland/restricted_apps.d/ containing the full path of the authorized app and the interfaces that are allowed. </blockquote> Some apps might need some confirmation (however it will look) like command line screenshooters or applications which are not installed and thus have no configuration file in /etc/wayland/restricted_apps.d/ which would allow them to use a restricted protocol. I guess there are even more cases. Essentially we need 3 parameters: the full path of the app, allowed interfaces and if the app requires user input. If the doesn't require input or has no configuration, we must present the user a confirmation dialog. </blockquote> It would work if you trust the screenshot application. <blockquote cite="mid:f312dae196fec35bc8130c8eae0ca59e@sebastianwick.net" type="cite"> I would be okay with that but I think an external program would be smarter to have a unified way of dealing with it. </blockquote> To be honest, I think the best solution is not to have a screenshot protocol at all and implement the solution [1] I described before. Hot keys to grab a window's output, screen output or screens output. Then, it should be saved to a file (doesn't have to be stored on the hdd) and a user-specified application could open the file (by its fd), display it to the user and do whatever it wants with it (crop, resize, whatever). This way, it is pretty simple for everyone and it really follows Wayland's way of being simple and secure. The video capture API concerns me more. </body> </html>