Le 07/01/2014 01:45, Sebastian Wick a écrit :
Am 2014-01-06 19:33, schrieb Martin Peres:
Le 06/01/2014 19:10, Sebastian Wick a écrit :
Am 2014-01-06 16:05, schrieb Martin Peres:
As I said before, I think trusting applications is taking the problem
the wrong way.
What we want is that a screenshot can only happen when the *user*
wants it.
This is why I think it is the desktop shell's job to launch the
screenshot app when
required by the user. In this case, even if the user can select the
application
that can perform a screen shot and even if a malicious application
changes
the default setting, it won't be able to perform screenshots silently.
This is what
we want.
It's just not flexible enough. What if you want to autostart a
screen-reader?
Please provide a better example, this one doesn't make sense. Who
would want that?
And if they do want that, they should press a button on their keyboard
to do just that.
Taking a screenshot from the command line with delay, recording the
desktop as
soon as a program starts. Making screenshots at a specific times.
There are some valid cases you can't even think of until someone wants
it.
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.
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.
Is it something that would be satisfactory to you?
My proposal is that it should require a physical key pressing to be
able to get ONE
screenshot means we also require a secure input method and can
attest the origin
of the key stroke but what else can be do? Of course, you should
also allow key
strokes from the on-screen keyboard, but this application should be
launched
by the compositor and should be trusted anyway. I should talk to Peter
Hutterer about
input security/origin.
Like I said, I think it's too inflexible.
Please, share a list of valid use cases :) I already gave reasons why
I think not doing what
I proposed almost means no confidentiality on the application's buffers.
Of course, it could be mitigated by making the screen flash or
something when a screenshot
is taken but people just hate that and some would even fail to notice
it.
What you want is allowing apps to grab the screen whenever you want.
Allowing that should
mean you have root/admin access. A global configuration file could
disable the screenshooting
security, but that should be a conscious choice of the administrator
(for whatever weird reason
they want to be able to grab the screen).
However, I re-iterate, this is something stupid security-wise for very
little benefit. Why don't you
want to associate a physical event to start the recording process?
I just don't agree that a restricted protocol is only useful if the user
interacts with it.
You may be right. I meant for screen grabbing (images or videos), no idea
what restricted interface could be useful for a wayland compositor.
Any idea?
That also means that we need a protocol to tell the compositor to
start a
program with a new socket and a protocol to ask the compositor for
permission.
Why do you want to create so many protocols? The compositor simply
has to create
a new connection to itself, mark this connection as being allowed to
do one screenshot,
then fork. The child should then exec the wanted process. The new
process will simply
access the already-opened fd and communicate with the server with it
(yes, some FDs
from the parent can still exist in the child process, after the exec).
That should be the way for privileged application to communicate with
the compositor.
No authentication protocol needed, the compositor is responsible for
doing
the authentication the way it pleases him.
You're right about the authentication protocol but there must be a way
to tell the
compositor to start an application without having a key-binding or
such a thing.
When a client uses the protocol, the compositor would then do what you
described.
Would it be ok for you if the compositor asked the user to agree for the
program to
do the operation? If so, we can guarantee that this is really the user's
intent and
allow the application. We can also add a security warning with a "Do not
ask again"
checkbox. Would it be satisfactory to you?
I don't really like mandating compositors to implement that much code,
but that's the only
secure way I see to allow the uses cases you want to allow.
By the way, I asked Peter about the security of input and that should be
good. We then
discussed about visual feedback as a mean to provide some mitigation and
show
some applications are grabbing the screen in the background. That may be
something you
would be interested in, in your case. What do you think?
Polkit should be flexible enough to allow a protocol based on how a
program
was started. You could configure polkit that if the compositor
started a program
because of a key-binding it has permission to use a protocol and
stuff like that.
I haven't studied polkit, I don't know.
I'm going to ask someone who knows more about polkit but from what I
understand we
can pass arguments to polkit rules.
We don't even have to argue about if only clients started by a user
action get
permission because we can simply pass to polkit if the client was
started by a user
action and let polkit decide.
Great, please report back!
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
