Trusted wayland client API (was: Limitations of Weston's screenshooter)

[Maarten Baert]

On 13/12/13 19:11, Jasper St. Pierre wrote:
> I'm curious how your rogue program could modify the link-time
> environment of a running Wayland compositor.
It doesn't have to attack the compositor, it can attack the clients instead.

To demonstrate that this is not just speculation on my part, I went
ahead and actually wrote a proof-of-concept. It wasn't much work anyway:
https://github.com/MaartenBaert/wayland-keylogger
Please don't take this as criticism. All I'm trying to say is that a
system that lacks sandboxing and mandatory access control is inherently
insecure, and we shouldn't pretend that it can be made secure with only
a server-side authentication protocol. We will need more than that.

On 13/12/13 19:11, Jasper St. Pierre wrote:
> I don't think that these things are things that mean we shouldn't give
> free-roam access to the Weston front-buffer contents. I don't think
> you think that either, I just want to double-check. Perhaps it makes
> sense to start thinking about a privileged API system for other users
> too: the a11y folks want to fake mouse clicks to apps, and that's not
> something we just want to give out to other apps either.
>
> I don't know if Kristian has thought about this at all. But what I
> think would sell most people would be to make a proof-of-concept that
> uses whatever security restriction mechanism you like to build your
> new screenshooter protocol, rather than just saying "security is hard,
> we shouldn't even try".
Correct, I don't think the screenshot protocol should be open to all
applications. I think an authentication API is the way to go.

On 13/12/13 20:32, Martin Peres wrote:
> Right, but that's no excuse for making it harder for people who want
> to control the security of their system. In view of the current events,
> we should really propose something that is as secure as possible
> *by default* and make it as easy as possible to improve with simple
> MAC rules (path- or label-based) for distros who want to focus on
> security.
Exactly, that's why I said that the security mechanism should integrate
well with SELinux and other existing security systems. Because those are
really the only ways to get any security at all. I want to avoid
security mechanisms that don't actually work and just give the user a
false sense of security, because that's arguably worse than having no
security at all.

If you show a popup to the user that says 'Application X wants to take
screenshots. Do you want to allow this? [Yes] [No]' then the user will
assume that applications cannot take screenshots without permission. If
this assumption is wrong, then the popup has actually made the system
*less* secure because it makes the user believe that no further security
mechanisms are needed.

And in case it wasn't clear, this assumption *is* wrong. I can
LD_PRELOAD a library into any application that is started by the user,
and let the application take screenshots of itself. This is how 'OpenGL
recording' in SSR works. I don't need permission from the compositor to
capture a single application, only to capture the entire screen.

On 16/12/13 00:21, Timothée Ravier wrote:
> If this kind of setting is included, it's going to become the default
> instantly, as no one is going to even try to do it the correct and
> secure way when there is another super easy (and insecure) way.
Exactly.


On 16/12/13 00:21, Timothée Ravier wrote:
> One way to do this is to add a setting to let the user choose which
> application should be started when a screenshot is requested.
This is fine for screenshot applications, but it doesn't cover any other
application that needs access to sensitive APIs for any other reason
(like screen recording apps, or any application that needs global hotkeys).

On 16/12/13 00:21, Timothée Ravier wrote:
> Another would be to create an interface to enable a user to ask the
> compositor to launch an application with a set of restricted interfaces
> enabled.
IMHO this method is far better than all the other suggestions. As far as
I can see it would eliminate all the unpredicatable side effects of the
execution environment (notably LD_PRELOAD, but also chroot). The trusted
application would run in an execution environment created by the
compositor. It is also simple to implement (i.e. it's less likely that
compositor developers will make mistakes that make it insecure) and
isn't too much of a hassle for the user.

However, there's one problem with this approach. Technically it is
secure, but it doesn't prevent applications from bombarding the user
with annoying popups. A rogue application could also show a popup that
is intentionally chosen to look very similar to a real popup (for
example, the application could try to launch 'gnome_screenshot' instead
of 'gnome-screenshot' and hope that the user won't see the difference.
The average user doesn't care about security and *will* simply press
accept/allow/ok/agree/yes to make it go away, if he/she is sufficiently
annoyed. Applications have trained users to click 'accept' whenever such
a dialog pops up, because they think it's needed to make the application
work (and usually it is).

So for that reason I'm proposing a modified version that also has a few
other advantages. The idea is really simple: the system has a directory
(e.g. /usr/share/trusted-wayland-clients/) where commands can be stored
that can then be executed by the compositor. Like
/usr/share/applications but only for trusted wayland clients. The files
could look like this:

[Trusted Wayland Client]
name=My screenshot application
exec=my-screenshot-application --some-command --some-other-command
allow-interfaces=wl_screenshot
show-warning-dialog=false

This would be a suitable configuration for a simple screenshot
application, as long as the application gives some kind of visual
indication that a screenshot has been taken (which most screenshot apps
do AFAIK). The 'show-warning-dialog' field would be set to 'true' for
more risky applications to make sure that the user is aware of what is
happening.

Another example, for an application that collects mouse and keyboard
statistics (if you think this is silly or dangerous, consider that
WhatPulse <https://en.wikipedia.org/wiki/Whatpulse> is very popular and
you probably won't be able to convince users to stop using it):

[Trusted Wayland Client]
name=Mouse and keyboard statistics collector
exec=mouse-and-keyboard-statistics
allow-interfaces=wl_global_mouse_listener;wl_global_keyboard_listener
show-warning-dialog=true

Now the compositor only has to expose an API that will run one of these
predefined commands. A possible extension would be to allow custom
arguments such as the system used in 'desktop files' (files in
/usr/share/applications/).

This approach is simple, should be suitable for all use cases I can
think of, and doesn't create too much hassle for the user. The only
limitation I see is that the user is required to have root access to add
its own Trusted Wayland Client. As far as I can see it's not possible to
fix this without compromising security, but I don't think it's actually
that important. How many users will compile applications from source on
a machine where they don't have root access, and can't ask the sysadmin
to install it for them?

On 16/12/13 00:21, Timothée Ravier wrote:
> Thus packaged screenshot applications can include a privileged setup
> step which add a file containing the application full path in a
> directory writable only by root
> (/etc/wayland/accepted-screenshoters.d/appname for example). The
> compositor would check all files in this directory before launching the
> application (or load the list of allowed applications at startup).
I don't think the path name alone is enough. I can LD_PRELOAD my code
into a trusted application. Maybe I can also set up a chroot to mess up
path names (not sure, this depends on how the path will be verified). I
would avoid the 'full path whitelist' approach and just let the
compositor launch the application instead - this avoids a lot of
potential weaknesses.

Maarten Baert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131219/e1b691dc/attachment-0001.html>