<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 13/12/13 19:11, Jasper St. Pierre wrote:<br>
<blockquote
cite="mid:CAA0H+QTvXaKCVgCrg06Vj_w8nMq1kVD3tihxBBcnruHMpwiH+g@mail.gmail.com"
type="cite">
<div dir="ltr">I'm curious how your rogue program could modify the
link-time environment of a running Wayland compositor.<br>
</div>
</blockquote>
It doesn't have to attack the compositor, it can attack the clients
instead.<br>
<br>
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:<br>
<a href="https://github.com/MaartenBaert/wayland-keylogger">https://github.com/MaartenBaert/wayland-keylogger</a><br>
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.<br>
<br>
On 13/12/13 19:11, Jasper St. Pierre wrote:<br>
<blockquote
cite="mid:CAA0H+QTvXaKCVgCrg06Vj_w8nMq1kVD3tihxBBcnruHMpwiH+g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.<br>
<br>
</div>
<div>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".<br>
</div>
</div>
</div>
</div>
</blockquote>
Correct, I don't think the screenshot protocol should be open to all
applications. I think an authentication API is the way to go.<br>
<br>
<div class="moz-cite-prefix">On 13/12/13 20:32, Martin Peres wrote:<br>
<blockquote type="cite">Right, but that's no excuse for making it
harder for people who want<br>
to control the security of their system. In view of the current
events,<br>
we should really propose something that is as secure as possible<br>
*by default* and make it as easy as possible to improve with
simple<br>
MAC rules (path- or label-based) for distros who want to focus
on<br>
security.</blockquote>
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.<br>
<br>
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 <b>less</b> secure because it makes the
user believe that no further security mechanisms are needed.<br>
<br>
And in case it wasn't clear, this assumption <b>is</b> 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.<br>
<br>
<div class="moz-cite-prefix">On 16/12/13 00:21, Timothée Ravier
wrote:<br>
</div>
<blockquote cite="mid:52AE398C.1040806@gmail.com" type="cite"> 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.<br>
</blockquote>
Exactly.<br>
<br>
<br>
<div class="moz-cite-prefix">On 16/12/13 00:21, Timothée Ravier
wrote:</div>
<blockquote type="cite">One way to do this is to add a setting to
let the user choose which<br>
application should be started when a screenshot is requested.</blockquote>
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).<br>
<br>
<div class="moz-cite-prefix">On 16/12/13 00:21, Timothée Ravier
wrote:</div>
<blockquote type="cite">Another would be to create an interface to
enable a user to ask the<br>
compositor to launch an application with a set of restricted
interfaces<br>
enabled.</blockquote>
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.<br>
<br>
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 <b>will</b> 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).<br>
<br>
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:<br>
<pre>[Trusted Wayland Client]
name=My screenshot application
exec=my-screenshot-application --some-command --some-other-command
allow-interfaces=wl_screenshot
show-warning-dialog=false</pre>
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.<br>
<br>
Another example, for an application that collects mouse and
keyboard statistics (if you think this is silly or dangerous,
consider that <a href="https://en.wikipedia.org/wiki/Whatpulse">WhatPulse</a>
is very popular and you probably won't be able to convince users
to stop using it):<br>
<pre>[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</pre>
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/).<br>
<br>
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?<br>
<br>
<div class="moz-cite-prefix">On 16/12/13 00:21, Timothée Ravier
wrote:</div>
<blockquote type="cite">Thus packaged screenshot applications can
include a privileged setup<br>
step which add a file containing the application full path in a<br>
directory writable only by root<br>
(/etc/wayland/accepted-screenshoters.d/appname for example). The<br>
compositor would check all files in this directory before
launching the<br>
application (or load the list of allowed applications at
startup).</blockquote>
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.<br>
<br>
Maarten Baert<br>
</div>
</body>
</html>