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