Authorized clients

[Martin Peres]

Le 10/01/2014 02:37, Sebastian Wick a écrit :
> 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.

I agree here, but you don't want to limit the number of screenshots the 
app can make? How, as a user, do you make sure the app you launched 
isn't running in the background?
>
> 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.

Seems good!
>
> 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.

So you trust that the application will behave correctly. If that's 
something all of you agree on, then I guess I'll consider it good-enough 
since the program is run by the compositor...
>
> 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.

just because a user clicks inside a window doesn't mean it the user 
meant to make a screenshot. If the application says "click here to win 
$100", the user has no idea that clicking will allow the application to 
make a screenshot.

Without a UDAC-like system, the compositor has no way to know the 
semantic behind a click, so it won't work. This case should open a pop 
up like c).

This is why I don't like this system, but I guess if you really want to 
allow applications to run a screenshot app, it does require a pop up and 
I don't find any way around it. This shouldn't be much of a problem 
because most users should use the "print screen" button anyway.
>
> 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.

Yes, I do agree but here is what I foresee: The configuration file to 
make your program work will be shipped by the distro, so it isn't really 
an input from the user to say "I agree with the security implication". 
Anyway, as much as I don't want that to happen, I guess it isn't 
wayland's problem anymore and that should be something the distro need 
to do.
>
> 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.
I meant the application's visual cue that it is taking a screenshot, not 
the compositor's. Anyway, we agree on that, there is no need to discuss 
this I guess.
>
> 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.

There will be very few compositors and it will be run by a lot of users. 
There may be tens of screenshot applications and a user may install 
several of them, increasing the attack surface even if he/she doesn't 
use them. But if I'm the only one concerned with that, I guess I should 
fold and call it good-enough. This is something we can improve later on, 
even if it means breaking some screenshot apps in the process (the ones 
we don't want to support any more).

Cheers,
Martin