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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
