Screencopy security

[ya-isakov]

Hello! I've realized that sway is breaking part of security model of Wayland, where other applications cannot see each other's windows. Sway is using screencopy manager from wlr, which allows any application, supporting screencopy protocol, to capture any part of the screen.
So, is it possible to allow user to restrict screencopy? Preferably with some dialog window, asking user's permission.

[emersion]

Duplicate of #2333

[ya-isakov]

So, the idea is to run xdg-desktop-portal-wlr and grim from sway itself, via exec, right?

[emersion]

xdg-desktop-portal-wlr is unrelated to our plans for security.

[ya-isakov]

I mean, it's also a user of screencopy protocol, and if the proposed security will be in place, xdg-desktop-portal-wlr will not be able to access screencopy manager, if I understand correctly - only if it will be run from sway's exec.

[emersion]

It's not yet clear how security will be implemented. We'll see.

[ya-isakov]

Got it. Is there a way to completely disable screencopy/dma-buf, for now?

[emersion]

I've been wondering about this. I think it would make sense to implement something like this in our config file. A rogue client that has write access to the config can do bad stuff anyway, like appending commands to ~/.profile.

[emersion]

@ddevault has NACKed a config file command to change this, he wants to wait for the broader Wayland security story to be fixed before. A build option could be added instead.

[ddevault]

To elaborate, I don't want to add new commands or config options or some similar such before we know how security as a whole is going to play out, because we'll have to support them forever and it's unlikely that we'd come up with a solution now that doesn't end up being inconsistent with our later work.

Build option to disable screencopy et al would be a great interim fix, though.

[ya-isakov]

I've applied custom patch, for now:

--- a/sway/server.c	2020-03-17 13:43:58.869424727 +0100
+++ b/sway/server.c	2020-03-17 13:44:10.268180142 +0100
@@ -132,8 +132,8 @@
 	wl_signal_add(&server->output_manager_v1->events.test,
 		&server->output_manager_test);
 
-	wlr_export_dmabuf_manager_v1_create(server->wl_display);
-	wlr_screencopy_manager_v1_create(server->wl_display);
+	//wlr_export_dmabuf_manager_v1_create(server->wl_display);
+	//wlr_screencopy_manager_v1_create(server->wl_display);
 	wlr_data_control_manager_v1_create(server->wl_display);
 	wlr_primary_selection_v1_device_manager_create(server->wl_display);

And yeah, build option would much better, as it will be more future-proof