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.
Let's not repeat X11's mistakes. Being too lax on security isn't good
for anyone.
By allowing some programs (and not the action), you expose yourself to
letting the
application record the screen without the user knowing and this is not
acceptable.
You would only allow certain functionality to trusted programs. If the
program
does something unexpected or malicious you should not trust the program.
You would also know which program uses which functionality so you
could inform
the user about it.
See, I hate the term "trusted". Just because a program is trusted
doesn't mean it is
cannot do anything malicious at some point. Even malicious doesn't mean
much since,
to me, malicious means doing something without the user expecting it.
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?
Martin, I would rather not use cgroups for that because it isn't
stable yet and I'm sure
we can find a solution that doesn't depend on it.
I do agree on this one but I'm not even sure how cgroups would be useful.
The problem we have is relatively simple. We want a protocol to be
restricted to
certain clients. Which means:
1. The program of the client must not be manipulated by ptrace,
LD_PRELOAD etc.
2. The communication must be separate from other clients to prevent
snooping
3. The compositor must decide if a client may use the protocol or not
The only way I know to achieve 1. is by starting the program by
another trusted
application. The compositor is one of them.
Making the communication separate works by passing a new socket to the
program
and the only way I know of is by passing it to the program when
starting it.
To decide if a client may use a protocol we could outsource the whole
decision
to polkit and just pass enough information so it can make a good
decision.
All in all I think the best and most simple way to do it is by
starting the
program by the compositor, passing a new socket, then let the client ask
for permission to use a protocol and pass the request to polkit.
The permission would be per-connection so if a program started by the
compositor starts another program with a client it would have the same
permission as the parent.
Fully agree on this.
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.
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.
Cheers,
Martin
PS: I hope I have managed to express my view in an understandable way
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
