Am 2014-01-10 01:05, schrieb Martin Peres:
Hey, don't twist his question and my answer ;) The question was IF our protocol is wrong. Remember, we aren't addressing the security of desktop here. We are looking for a way to provide a service (screenshots) and trying to find a way to make it as difficult as possible to misuse it. Right?
With emphasis on "providing a service". You say that we should not provide the service which just won't work because some people need it. So instead of saying that we should not implement it would be better to find the most secure way to do this. I proposed 2 solutions already and I still think that they are as secure is it can get.
You want that every use of a restricted protocol is the cause of an user action and I think it is:
a) If you press a key-binding to launch a client which uses a restricted protocol you have a user action.
b) If a client (which can be a program and not the user) asks the compositor to launch a client which uses a restricted protocol and no matching configuration file can be found, the compositor requires the user to confirm or deny the request. That's obviously an user action, too.
c) If a client (which can be a program and not the user) asks the compositor to launch a client which uses a restricted protocol and a configuration file is found and the configuration says that the client DOES NOT require user input before using the protocol, the compositor requires the user to confirm the authorization. Again, user input.
d) If a client (which can be a program and not the user) asks the compositor to launch a client which uses a restricted protocol and a configuration file is found and the configuration says that the client requires user input before using the protocol, the user has to use the program and click or press a key. Those events come from the kernel, go to the compositor and over a secure connection to the trusted client. This is no different from having a key-biding in the compositor. Even this case requires user input.
You only have to trust that the client is not malicious like you also have to trust your compositor to not being malicious. If you don't want to trust the client then you obviously should not create a configuration in the trusted clients directory.
Then, in another mail you said:
The only thing we disagree about it the "trusted" label. At first, you trust the app, but then, there is a new version that allows disabling the visual cues and settings are stored in a file owned by the user. Then an attacker simply has to change the settings, run the app in the background and get the images. So, as I said, I don't trust application developers for doing the right things!
The whitelist for trusted applications must be only writable by root. That's why we don't want to mix it with the weston.ini configuration. Nobody said that we disable visual cues. The compositor knows which restricted protocols a client can access. You are free to implement a solution which shows it to the user in whatever form pleases you.
You don't even have to trust application developers. The configuration file can be created by the packager of your repository or by anyone else. What I don't understand is why you trust the compositor but not an application. There is no difference in why you should trust the one but not the other.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
