Authorized clients

[Martin Peres]

Le 08/01/2014 21:20, Sebastian Wick a écrit :
> Am 2014-01-08 19:53, schrieb Martin Peres:
>> Le 08/01/2014 17:20, Sebastian Wick a écrit :
>>> Am 2014-01-07 15:07, schrieb Martin Peres:
>>>> 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.
>>>
>>> Why should those people have worse security then others only because
>>> they want a feature you define as non-standard?
>>
>> 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).
>
> 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.

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.
>
>>>> 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.
>>>
>>> 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.
>>
>> 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.
>
> 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.

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.
>
>> 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.
>
> 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.

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 ( 
http://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket) 
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.
>
> 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.

I agree with that. Hence why we should limit the amount an app can make 
without user interaction.
>
>> 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.
>
> 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.

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.

>
> 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.

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 ;)
>
> 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.

Yes, but only a physical user can press this key. This is like pressing 
a button on the screen with a mouse.
>
> 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).

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.
>
>> 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)
>
> Like I said, we can configure certain application to not require a 
> confirmation dialog.
>
>> 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.
>
> 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.

It would work if you trust the screenshot application.
>
> I would be okay with that but I think an external program would be 
> smarter to have a unified way of dealing with it.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140109/a9ef4cf0/attachment.html>