Authorized clients

[Sebastian Wick]

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.

> 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?

I just don't agree that a restricted protocol is only useful if the user
interacts with it.

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

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.

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

> Cheers,
> Martin
> 
> PS: I hope I have managed to express my view in an understandable way

I do understand where you're coming from. I just don't think that we 
have to solve
the problem when others can do it for us.