Limitations of Weston's screenshooter / Are there any plans to create an official screenshot protocol?

[Maarten Baert]

On 13/12/13 16:01, Martin Peres wrote:
> I may be wrong, but other unix users shouldn't be able to
> communicate with another user's compositor unless this
> user specifically allowed that by adding him to his/her group.
Okay, then that's not an issue.

> Screenshot/screencapture applications are a confidentiality hazard.
> We don't want any application run by the user to be able to
> read the credit card number you are writing in firefox, right?
True, but sadly there are many other ways for applications to steal data
from other programs, if both applications are running as the same user.
A rogue application could simply read the firefox profile and steal
cookies and passwords. In fact, it could install a fake firefox (or
replace 'sudo', or even the wayland server) simply by changing PATH in
~/.profile. Or it could use LD_PRELOAD to inject a library and override
any system or library function it wants (e.g. wl_keyboard_add_listener).
I can write a proof-of-concept 'Wayland keylogger' to demonstrate it, if
you want.

A simple restriction in Weston is not enough to stop this. Only a system
like SELinux can fix this. With this in mind, I think the ideal
authentication system would be one that integrates well with existing
security/sandboxing mechanisms so that it can be enabled with minimal
hassle in places where it's important, while accepting that local
applications running outside the sandbox simply can't be stopped from
doing bad things. The current solution just gives a false sense of
security IMHO.

I have no experience with SELinux so I'm not sure how such a mechanism
should work. But it seems that both X11 and PulseAudio use a cookie
mechanism, where they put a random string (e.g. from /dev/urandom) in a
file in the home directory of the user. The file mode is 600 so only the
owner can read it. Wayland could use a similar mechanism, except that
the cookie would only be needed for unsafe actions like taking
screenshots or listening to global hotkeys. SELinux can then block
applications that want to open that file. Since the cookie is simply a
random string, it can be easily transferred to an application that would
otherwise not be allowed to read it. For example, an untrusted
application that isn't allowed to read the cookie directly could run a
trusted application which would show a popup asking the user whether the
untrusted application should be allowed to capture the screen. If the
user accepts, the trusted application will read the cookie and give the
result to the untrusted application. This is only an example of course,
but it shows one big advantage of this approach; it separates the
security/sandboxing mechanism from the compositor, and the only thing
the compositor has to do is write a random string to a file at startup.
The same security/sandboxing mechanism would be compatible with any
wayland compositor that follows this simple protocol.

In any case, I don't think putting all security-sensitive functionality
in the compositor is the best approach. It would lead to a very bloated
compositor, and as far as I understand that's exactly what Wayland tries
to avoid. I'm also worried that a design like that would simply
encourage users to disable the restrictions completely because they need
to run some application that needs access to the screen, or global
hotkeys, or a similarly sensitive feature. The average user still favors
functionality over security, so any security mechanism that is too much
of a hassle will simply be disabled.

In this case, the application that I've created is completely useless
without the ability to record the screen, because that's its primary
function. It is not a feature I can drop. It is technically possible to
let the compositor start my application, but that would mean I have to
modify every existing Wayland compositor. If there is no authentication
mechanism, then the only practical thing I can do is tell the users to
completely disable the restrictions of their Wayland compositor, and
that is really something I want to avoid.

On 13/12/13 16:07, Giulio Camuffo wrote:
> I don't think so, but you don't need to wait anything to start working
> on it. ;)
> [...]
> I think the protocol in weston was made just to showcase the way such
> a protocol would work, the "official" one would allow that.
Okay, so the screenshooter interface is essentially a work-in-progress
that will eventually become part of Wayland?

> I think the best solution would be to have a way to configure in the
> shell/compositor the trusted clients, and maybe a way for any client
> to ask the permission to bind to a restricted interface, which would
> pop up a request to the user.
I agree, but I think this should only be done for applications that are
running inside a sandbox. Any application that's not sandboxed can
essentially do whatever it wants, the popup would be useless and just
provide a false sense of security.

> I see two possible solutions:
> - the screenshooter_shoot request could carry a serial which the done
> event sends back later
> - the screenshooter_shoot returns a screenshoot object which has the
> done event
The first solution is very simple and would be fine for what I need.
However, wouldn't it make more sense to use a wl_callback object? It
sounds like this is exactly what wl_callback is meant for.

Maarten Baert