[PATCH weston] introduces a setting to give permission to any client to do screenshots

Timothée Ravier siosm99 at gmail.com
Sun Dec 15 15:21:48 PST 2013


On 15/12/2013 17:13, Martin Peres wrote:
> On 15/12/2013 01:09, Sebastian Wick wrote:
>> Am 2013-12-13 16:12, schrieb Martin Peres:
>>> What prevents other applications from modifying this setting to true
>>> if they want to
>>> spy on applications?
>>
>> Nothing. But then again if you can write to the ini file you can make
>> the compositor load any code with the shell setting.
> 
> Not if the compositor was loaded by the init system.

Or if you apply mandatory access control to restrict which files can be
loaded as shells by the compositor.

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.

>> I don't even think my patch is the right way to handle it anymore.
>> There must be a way to trust a client even when it's not started by
>> the compositor.
> I think there is one, but it is not super pretty:
> Write the list of acceptable screenshot clients in an
> administrator-owned file.
> The file could either be global (in /etc/) or local (in ~/.wayland/). To
> be found 
> acceptable by weston, it would have to be owned by root and in 644.

According to me, this is the good way. But first, let's recap on what
users want and what's acceptable from a security point of view:

* The user should be allowed to choose which screenshot/video recording
application to use;
* The user expects that only applications it explicitly launched should
be able to take screenshots;

Thus:

* Access to the screenshot interface should be restricted.
* The easiest way to give an application access to compositor
"restricted" interfaces is to let the compositor launch them.
* 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.
* 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.

This would ensure that the access to the restricted interface as been
explicitly asked and is not given by default.

In order to restrict which applications should be given access to this
interface, I suggest the following:

* Screenshot applications can be put into two categories:
- system wide binaries generally installed using a package manager;
- custom built binaries/applications compiled from source for example.
(This distinction matters as with system wide binaries, a privileged
setup step can be included)
* We want to allow accesses by default for system wide applications.
* We want the user to confirm accesses by custom applications.

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).

If the application is not listed in this file, a confirmation window
should be displayed (requesting the user password). To make the setting
permanent, administrative rights would be required. For this, polkit
could be used.

Thus it is dead simple to add new screenshot applications for
testing/development (run as root: echo /path/to/app >
/etc/wayland/accepted-screenshoters.d/appname and (maybe) restart the
compositor) and only a packager validated set of applications are
allowed access by default.

For the truly paranoid, a setting could be added in a root owned global
config file to force the dialog to be displayed for each screenshot request.

> In order to be considered "secure", the screenshot app shouldn't be able
> to take snapshot without the user's consent or, at least, the user should
> notice about it. That means no CLI-only interface without, at least,
> some sort of graphic notification.

I think this is a good idea. Maybe the compositor should display a large
explicit screenshot logo right after a screenshot is taken so that a
user looking at the screen would not miss it. This would also provide
feedback to the user.

The same thing could be done for screen recording.

Cheers
-- 
Timothée Ravier


More information about the wayland-devel mailing list