Authorized clients

[Jasper St. Pierre]

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.

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?

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.

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.

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.

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?



On Thu, Jan 9, 2014 at 6:40 AM, Martin Peres <martin.peres at free.fr> wrote:

>  Le 08/01/2014 21:20, Sebastian Wick a écrit :
>
> Am 2014-01-08 19:53, schrieb Martin Peres:
>
> Le 08/01/2014 17:20, Sebastian Wick a écrit :
>
> Am 2014-01-07 15:07, schrieb Martin Peres:
>
> Those are extremely rare cases. Users wanting to do that should agree
> they give up
> confidentiality and should thus be administrators in order to tell the
> compositor that.
>
>
> Why should those people have worse security then others only because
> they want a feature you define as non-standard?
>
>
> That's not what I meant. I meant that if they want what you say you
> want to allow,
> they will de-facto loose some security (namely, confidentiality if the
> screenshot
> app is misbehaving).
>
>
> 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.
>
>
> 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.
>
> 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
>
> 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.
>
>
>  In this case, we can still restrict access to the interface to a
> handful of programs
> to lower the risks, but it will still be possible for these
> applications to spy on the user
> without him knowing and this is something that shouldn't be allowed by
> default.
>
>
> Like I said, we should be able to let polkit decide. You could even
> distribute
> a .rules file which white-lists an application if we pass the executable
> path.
>
>
> It is indeed something that is good, but insufficient because the
> trusted programs
> can do whatever they want and the compositor won't be able to tell if what
> they
> request really is what the user wants.
>
>
> 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.
>
>
> 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.
>
>
> Simple example, you want a CLI application
> to be able to make screenshots and save them to a file.
>
> As an attacker, if I want a screenshot, I'll just run the program and
> get the screenshot.
> Is that something you think is OK, I definitely think this is not.
>
>
> 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.
>
>
> 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:
> 1) full path of the app requesting that (if we can make sure of it when it
> has not been started by the compositor)
> 2) number of screenshots since the last time the "Print screen" event
> happened
>
> It seems 1) is doable (
> http://stackoverflow.com/questions/8104904/identify-program-that-connects-to-a-unix-domain-socket)
> and 2) should be doable.
>
> 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.
>
>
> 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.
>
>
> I agree with that. Hence why we should limit the amount an app can make
> without user interaction.
>
>
> This is why I said the compositor shouldn't agree on a screenshot
> request if it can't
> tell if it was a user-made request or an app-made one.
>
>
> 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.
>
>
> 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).
>
> Is program B buggy or illegitimate? No, it does exactly what the user
> wants and is fine on its own.
> Does it trash the graphics output confidentiality of the whole computer?
> Yes!
>
> 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....
>
> 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.
>
>
>
> 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.
>
> 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.
>
>
> 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 ;)
>
>
> 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.
>
>
> Yes, but only a physical user can press this key. This is like pressing a
> button on the screen with a mouse.
>
>
> 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).
>
>
> 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.
>
>
> The only solutions we found so far have been:
> - listen for hot keys from an input device (we have to trust the
> kernel for not allowing to forge events)
> - require a confirmation of some sort (popup / systray icon / whatever)
>
>
> Like I said, we can configure certain application to not require a
> confirmation dialog.
>
> The decision making is just what it is, a decision. This is an
> implementation detail.
> You propose to use polkit for the decision making, why not? But I
> think this is overkill since
> we only need a file in /etc/wayland/restricted_apps.d/ containing the
> full path of the authorized
> app and the interfaces that are allowed.
>
>
> 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.
>
> 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.
>
>
> It would work if you trust the screenshot application.
>
>
> I would be okay with that but I think an external program would be smarter
> to have a unified way of dealing with it.
>
>
> 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.
>
> The video capture API concerns me more.
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140109/389eb4b3/attachment-0001.html>