Authorized clients

[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.

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