<div dir="ltr"><div><div>Security is based on trust. If you trust nothing, the computer won't do very much for you. You can't even trust it to compute correctly.<br><br></div><div>What's the threat model here? Let's say that we design a screenshot API, and in your opinion it's the worst thing ever. Who's attacking? How are they attacking? How will you mitigate it?<br>
<br></div><div>In our threat model of sandboxed applications, which takes inspiration from Android, apps are given a coarse-grain set of permissions: this app can take screenshots. That app can access your contact list.<br>
<br></div><div>These are guarantees that the user can see, and the system can provide. If the Flashlight app requires bluetooth, then something sketchy might be going on, and the user can "vote with their feet" and install a separate app.<br>
<br></div><div>Locking down permissions UAC-style does not provide additional security. Again, when the user is accomplishing a task, and you give them a security prompt, you will get answers worse than random chance. The user is doing something, now they have to make a decision about yes/no. They are often ill-equipped to handle such questions.<br>
</div><br>If they press a "Take Screenshot" button in the app, and the user is now prompted with a "Are you sure you meant to take a screenshot?" prompt, what happens if they hit No to get rid of the annoying prompt? What does the app do? What does the user do?<br>
</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 6:40 AM, Martin Peres <span dir="ltr"><<a href="mailto:martin.peres@free.fr" target="_blank">martin.peres@free.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Le 08/01/2014 21:20, Sebastian Wick a
écrit :<br>
</div><div class="im">
<blockquote type="cite">Am 2014-01-08 19:53, schrieb Martin Peres:
<br>
<blockquote type="cite">Le 08/01/2014 17:20, Sebastian Wick a
écrit :
<br>
<blockquote type="cite">Am 2014-01-07 15:07, schrieb Martin
Peres:
<br>
<blockquote type="cite">Those are extremely rare cases. Users
wanting to do that should agree
<br>
they give up
<br>
confidentiality and should thus be administrators in order
to tell the
<br>
compositor that.
<br>
</blockquote>
<br>
Why should those people have worse security then others only
because
<br>
they want a feature you define as non-standard?
<br>
</blockquote>
<br>
That's not what I meant. I meant that if they want what you say
you
<br>
want to allow,
<br>
they will de-facto loose some security (namely, confidentiality
if the
<br>
screenshot
<br>
app is misbehaving).
<br>
</blockquote>
<br>
I don't understand you. You trust the compositor to do the right
things, why shouldn't you trust a screenshot app to do the right
things? I mean, if you make a screenshot via a key-binding you
also trust weston-screenshooter to not screw up. You have to trust
the application if you want to give it access to a privileged
protocol.
<br>
</blockquote>
<br></div>
The compositor has to be trusted. It has access to all the
application's output buffer. What we want is to avoid other apps
from getting them unless that's what the user intended to. This
intent can be known by the compositor through the input devices.<br>
<br>
We don't need to trust the client much if we limit the number of
screenshots to 1. This way, the worse thing that could happen for
your privacy would be if your cat sits on the keyboard and presses
"print screen" all the time while you key in sensitive information
(unlikely, right?), even if the app just <br>
<br>
When you trust an application to always do the right thing, it can
abuse its power in the user's back and I don't like that.<div class="im"><br>
<blockquote type="cite">
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">In this case, we can still restrict
access to the interface to a
<br>
handful of programs
<br>
to lower the risks, but it will still be possible for these
<br>
applications to spy on the user
<br>
without him knowing and this is something that shouldn't be
allowed by default.
<br>
</blockquote>
<br>
Like I said, we should be able to let polkit decide. You could
even distribute
<br>
a .rules file which white-lists an application if we pass the
executable path.
<br>
</blockquote>
<br>
It is indeed something that is good, but insufficient because
the
<br>
trusted programs
<br>
can do whatever they want and the compositor won't be able to
tell if what they
<br>
request really is what the user wants.
<br>
</blockquote>
<br>
Of course they can. Every client can do whatever they want. Even
when taking a screenshot in weston via a key-binding you launch
weston-screnshooter and it can do whatever it wants to do. The
only way to be sure that it does exactly what you want it to do is
by reading the source code.
<br>
</blockquote>
<br></div>
This is not true. The server can refuse to feed the application with
more than one screenshot. This severely restricts the possibilities
of using this feature to spy on what a user is doing.<div class="im"><br>
<blockquote type="cite">
<br>
<blockquote type="cite">Simple example, you want a CLI application
<br>
to be able to make screenshots and save them to a file.
<br>
<br>
As an attacker, if I want a screenshot, I'll just run the
program and
<br>
get the screenshot.
<br>
Is that something you think is OK, I definitely think this is
not.
<br>
</blockquote>
<br>
It's not okay. You should not give the application permission to
use the screenshoter protocol without further restrictions, then.
If we would use polkit you could configure it so that the
application gets access to the restricted protocol if it is
started with root permission or after you entered your password.
<br>
</blockquote>
<br></div>
The only way I could possibly agree with you on this would be to
have authentication on every call to the screenshot API with the
following parameters:<br>
1) full path of the app requesting that (if we can make sure of it
when it has not been started by the compositor)<br>
2) number of screenshots since the last time the "Print screen"
event happened<br>
<br>
It seems 1) is doable (
<a href="http://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket" target="_blank">http://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket</a>)
and 2) should be doable.<br>
<br>
However, I don't like the idea of having to audit the policy on
every wayland computer I will be on especially since I'm pretty sure
some devs won't mind if their application is a privacy killer.<div class="im"><br>
<blockquote type="cite">
<br>
Oh, and if you make a screenshot, no matter how, and save it to
disk, it is readable by any other application you start. It's not
our job to prevent that.
<br>
</blockquote>
<br></div>
I agree with that. Hence why we should limit the amount an app can
make without user interaction.<div class="im"><br>
<blockquote type="cite">
<br>
<blockquote type="cite">This is why I said the compositor
shouldn't agree on a screenshot
<br>
request if it can't
<br>
tell if it was a user-made request or an app-made one.
<br>
</blockquote>
<br>
That's wrong. It should not matter who made the request. If you
can use a program to exploit the security, the program is broken
or has the wrong security settings.
<br>
</blockquote>
<br></div>
I want to make sure you understand the concept of indirect
interactions. If program A cannot access the screenshot API but
program B can and program B can be made to save the file
automatically without the user knowing, then program A can call
program B and get whatever he wanted (I never trust a screenshot app
to do the right thing).<br>
<br>
Is program B buggy or illegitimate? No, it does exactly what the
user wants and is fine on its own.<br>
Does it trash the graphics output confidentiality of the whole
computer? Yes!<br>
<br>
What if I use a computer and someone installed such an app (shared
computer, for instance)? Well, I won't know I lost the
confidentiality. Too bad....<br>
<br>
This is why we need the user's input, either a run-time enable as
Pekka suggested or a hot key one as I suggest. Both can be
implemented if needed, they cover different use cases.<div class="im"><br>
<br>
<blockquote type="cite">
<br>
If you have a screenshot UI and it gets started (by whoever) the
user must do something for the application to actually take the
screenshot, otherwise it's broken.
<br>
<br>
If you have a command line app to make screenshots and someone or
something wants to start it there must be some kind of user
interaction to confirm it.
<br>
</blockquote>
<br></div>
I fully agree here but contrarily to you, I don't want to trust the
application. Anyway, glad to see we are on almost the same page ;)<div class="im"><br>
<blockquote type="cite">
<br>
If you press a key-biding and the compositor starts an application
to make a screenshot there doesn't need to be a confirmation. We
simply start the app and be done with it.
<br>
</blockquote>
<br></div>
Yes, but only a physical user can press this key. This is like
pressing a button on the screen with a mouse.<div class="im"><br>
<blockquote type="cite">
<br>
So we can have a configuration which only allows access to
restricted protocols if the user agrees to it (or something else,
this is really up to the one who configures the system). If the
request to start the application comes from the compositor itself
we can safely assume that everything is fine and start to app. If
the request to start the application comes from another client, we
check the configuration. If the configuration says it's fine to
start the app, we do so (however it will determine if it's okay or
not; maybe the app is configured to just start, maybe the app is
configured to require the user to press on a "yes" button, maybe
the app is configured to require the user to enter his password or
maybe it is simply configured to deny the request).
<br>
</blockquote>
<br></div>
Yep, that would be a good fallback but as I said before, if someone
installs such an app on my computer and it can do screen captures
without my interaction, then I just lost the confidentiality of my
desktop. I just don't like the concept of not further checking how
the app is using the interface.<div class="im"><br>
<blockquote type="cite">
<br>
<blockquote type="cite">The only solutions we found so far have
been:
<br>
- listen for hot keys from an input device (we have to trust the
<br>
kernel for not allowing to forge events)
<br>
- require a confirmation of some sort (popup / systray icon /
whatever)
<br>
</blockquote>
<br>
Like I said, we can configure certain application to not require a
confirmation dialog.
<br>
<br>
<blockquote type="cite">The decision making is just what it is, a
decision. This is an
<br>
implementation detail.
<br>
You propose to use polkit for the decision making, why not? But
I
<br>
think this is overkill since
<br>
we only need a file in /etc/wayland/restricted_apps.d/
containing the
<br>
full path of the authorized
<br>
app and the interfaces that are allowed.
<br>
</blockquote>
<br>
Some apps might need some confirmation (however it will look) like
command line screenshooters or applications which are not
installed and thus have no configuration file in
/etc/wayland/restricted_apps.d/ which would allow them to use a
restricted protocol. I guess there are even more cases.
<br>
<br>
Essentially we need 3 parameters: the full path of the app,
allowed interfaces and if the app requires user input. If the
doesn't require input or has no configuration, we must present the
user a confirmation dialog.
<br>
</blockquote>
<br></div>
It would work if you trust the screenshot application.<div class="im"><br>
<blockquote type="cite">
<br>
I would be okay with that but I think an external program would be
smarter to have a unified way of dealing with it.<br>
</blockquote>
<br></div>
To be honest, I think the best solution is not to have a screenshot
protocol at all and implement the solution [1] I described before.
Hot keys to grab a window's output, screen output or screens output.
Then, it should be saved to a file (doesn't have to be stored on the
hdd) and a user-specified application could open the file (by its
fd), display it to the user and do whatever it wants with it (crop,
resize, whatever). This way, it is pretty simple for everyone and it
really follows Wayland's way of being simple and secure.<br>
<br>
The video capture API concerns me more.<br>
</div>
<br>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br> Jasper<br>
</div>