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

[Jasper St. Pierre]

On Fri, Dec 13, 2013 at 12:57 PM, Maarten Baert
<maarten-baert at hotmail.com>wrote:

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

I'm curious how your rogue program could modify the link-time environment
of a running Wayland compositor.

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.

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

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 don't think there was any intention to allow an official screenshooter
protocol. If there was, I think we'd want it out-of-tree for now.


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

Yeah, wl_callback is a generic "I need a 'done' event" thing here.


> Maarten Baert
> _______________________________________________
> 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/20131213/bf9661e9/attachment.html>