Authorized clients

[Sebastian Wick]

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.