Authorized clients

[Sebastian Wick]

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.

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

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

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.

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

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.

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.

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

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

I would be okay with that but I think an external program would be 
smarter to have a unified way of dealing with it.