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