Authorized clients

[Sebastian Wick]

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.