Authorized clients

Tue Jan 7 11:26:36 PST 2014

On Tue, Jan 7, 2014 at 9:07 AM, Martin Peres <martin.peres at free.fr> wrote:

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

The user opened up a screen recording app. The user's intent is very much
to record the screen. We don't need to ask the user again with a prompt.

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

-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140107/7291ea8d/attachment-0001.html>