Authorized clients

[Martin Peres]

Le 08/01/2014 17:20, Sebastian Wick a écrit :
> Am 2014-01-07 15:07, schrieb Martin Peres:
>> 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.
>
> Why should those people have worse security then others only because
> they want a feature you define as non-standard?

That's not what I meant. I meant that if they want what you say you want 
to allow,
they will de-facto loose some security (namely, confidentiality if the 
screenshot
app is misbehaving).
>
>> 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.
>
> Like I said, we should be able to let polkit decide. You could even 
> distribute
> a .rules file which white-lists an application if we pass the 
> executable path.

It is indeed something that is good, but insufficient because the 
trusted programs
can do whatever they want and the compositor won't be able to tell if 
what they
request really is what the user wants. Simple example, you want a CLI 
application
to be able to make screenshots and save them to a file.

As an attacker, if I want a screenshot, I'll just run the program and 
get the screenshot.
Is that something you think is OK, I definitely think this is not.

This is why I said the compositor shouldn't agree on a screenshot 
request if it can't
tell if it was a user-made request or an app-made one. The only 
solutions we found
so far have been:
- listen for hot keys from an input device (we have to trust the kernel 
for not allowing to forge events)
- require a confirmation of some sort (popup / systray icon / whatever)

The decision making is just what it is, a decision. This is an 
implementation detail.
You propose to use polkit for the decision making, why not? But I think 
this is overkill since
we only need a file in /etc/wayland/restricted_apps.d/ containing the 
full path of the authorized
app and the interfaces that are allowed.

>
>> 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?
>
> The GNOME accessibility team need a few restricted protocols. Don't 
> know about
> the details, though.

I would be interesting in knowing what they have been thinking about!
>
>> 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?
>
> If an application has the permission to use an restricted protocol it 
> already
> met all the requirements. You should talk to the polkit dev if you 
> want such
> an feature, I guess.

See, that's where we disagree. An app can get hijacked or used in 
conjunction with others
apps to make it around the security policy you want to set.

I used to work in a research security team and one of the project we 
used was PIGA which
essentially is a language to define security properties and a compiler 
was then responsible
for checking all the ways there was to violate the security property 
wanted (with the SELinux
policy as an input of all the allowed operations). There were hundreds 
of thousands of ways to
go around trivial security properties such as "do not allow a 
user-written file to be executable".

Can you certify all the screenshot apps won't be able to be used in a 
malicious way, if not
directly, indirectly? I can't and I think no-one can.

>
>> 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.
>
> And that's exactly why I don't want to implement the authorization 
> checking
> in the compositor! We can safely let polkit decide in non-obvious cases.
> Less code in the compositor, less duplicated code and less security risks
> because polkit is designed to do that.

Maybe. It doesn't solve the security issue though ;)
>
>> 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?
>
> I'm personally not interested in it but I guess it's a nice feature 
> for some
> people and I don't see why it should not work.

I do see why it shouldn't work. It would not be standardized, users 
wouldn't understand,
that would become annoying, users would deactivate it, unaware they are 
being spied on.