Authorized clients

[Martin Peres]

Le 07/01/2014 01:45, Sebastian Wick a écrit :
> 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.

Those are extremely rare cases. Users wanting to do that should agree 
they give up
confidentiality and should thus be administrators in order to tell the 
compositor that.

In this case, we can still restrict access to the interface to a handful 
of programs
to lower the risks, but it will still be possible for these applications 
to spy on the user
without him knowing and this is something that shouldn't be allowed by 
default.

Is it something that would be satisfactory to you?
>
>>
>>>
>>>> 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.

You may be right. I meant for screen grabbing (images or videos), no idea
what restricted interface could be useful for a wayland compositor.

Any idea?
>
>>
>>> 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.

Would it be ok for you if the compositor asked the user to agree for the 
program to
do the operation? If so, we can guarantee that this is really the user's 
intent and
allow the application. We can also add a security warning with a "Do not 
ask again"
checkbox. Would it be satisfactory to you?

I don't really like mandating compositors to implement that much code, 
but that's the only
secure way I see to allow the uses cases you want to allow.

By the way, I asked Peter about the security of input and that should be 
good. We then
discussed about visual feedback as a mean to provide some mitigation and 
show
some applications are grabbing the screen in the background. That may be 
something you
would be interested in, in your case. What do you think?

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

Great, please report back!