Authorized clients

[Martin Peres]

Le 04/01/2014 11:01, Martin Graesslin a écrit :
> On Tuesday 31 December 2013 05:02:30 Sebastian Wick wrote:
>> I'm currently working on a system which allows specific clients to use
>> restricted interfaces [1]. This is needed for applications like
>> screenhooters,
>> desktop recorders outside of the compositor, accessibility tools and
>> others.
> Thanks for looking into this interesting topic. It's an important use case for
> us in the KDE world as compositor and desktop shell are in different processes.
>
> I will try to share my thoughts so far and I must say that I don't know
> whether that's implementable at all. Of course we also thought about working
> with full paths, but I don't think that's a good solution for a flexible
> desktop environment such as Plasma. Also it creates a terrible linear chain in
> the startup - we want to move to a more flexible framework and don't turn KWin
> into another system startup process. It might be a solution for things like
> KSnapshot but certainly not to bring up the desktop shell.
>
> The idea I have so far is to depend on cgroups and namespaces. Thus everything
> which needs the more privileged interfaces needs to be in the "desktop shell"
> cgroup. I hope that we can make use of systemd to provide us such features.
> Clients which are not in the trusted group will not get the more exposed
> interfaces.
>
> This could also work for things like screenshooters, but here we start to
> enter trust issues again. We certainly would trust a KDE application, but
> that's already quite borderline. For such cases so far I only have the idea of
> nag screens like UAC. I hate that and absolutely don't want to implement it.
> So I'm looking forward for good solutions. Polkit could be a nice solution to
> that.
>
> I'm not so sure about configuration files as I don't believe in whitelists in
> general :-) Obviously it allows the distribution to properly setup the system
> but there might be better solutions to that. My suggestion here is to specify
> the interfaces in the desktop file.
>
> Cheers
> Martin

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.

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.

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.

The proposed authentication scheme you are trying to propose can however 
act as a
second level of security so as only trusted (by the distro) apps would 
be able to be grab
the screen.

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.

Cheers,
(The other) Martin