security

[dkwo]

Does river have any way to handle which clients (if any) can capture screen (say wlr-screencopy), read clipboard, capture keystrokes, inject input, etc? can any user with access to my XDG_RUNTIME_DIR and WAYLAND_DISPLAY do that? in which case, is one supposed to use pipewire or similar to contain untrusted apps?

[dkwo]

One possibility is that the compositor offers different Wayland sockets, possibly tag windows accordingly, and confirm wlr-screencopy and similar across boundaries.

[Leon-Plickat]

Does river have any way to handle which clients (if any) can capture screen (say wlr-screencopy), read clipboard, capture keystrokes, inject input, etc?

No.

can any user with access to my XDG_RUNTIME_DIR and WAYLAND_DISPLAY do that?

Yes.

in which case, is one supposed to use pipewire or similar to contain untrusted apps?

You would need to use some sort of sandbox (flatpak uses bubblewrap AFAIK) and only expose the portals service to the application, which in term could ask you before taking a screenshot. xdg-desktop-portal-wlr can be used for screenshots and screenrecordings through portals on wlroots based compositors. You can IIRC change the commands it uses to do so, so that the user will be notified of any screencopy operation and can choose to deny it.

Setting sandboxing with portals up manually is a bit of a hassle. If you care about this, you might want to consider using flatpak (you can also create local flatpak packages from self-compiled software with their docs, if you need that).

---

Security is a seriously hard issue. Using different sockets is an idea that often comes up, but things like PID-spoofing make it ineffective. You can find various discussions about this on the Wayland mailing list, the Wayland IRC channel logs and the Wayland gitlab.

From what I can tell, super tight security isn't really possible right now thanks to UNIX being UNIX. However smart people are thinking about it, so I expect it to happen eventually. We are better off waiting until then and doing it properly than implementing some half-baked workaround in river that gives people the false sense of security.

Still, what we offer is already lightyears ahead of X. For example, we will have actually functional screen locking in the near future.

[dkwo]

That makes sense.

On a more basic level: is it possible to disable wlr-screencopy and similar stuff with build options, as we do for xwayland?

[ifreund]

On a more basic level: is it possible to disable wlr-screencopy and similar stuff with build options, as we do for xwayland?

No, and I'm not interested in adding any more build options than the xwayland toggle. If you'd like to disable wlr-screencopy the patch is trivial:

diff --git a/river/Server.zig b/river/Server.zig
index 830f5c9..a285278 100644
--- a/river/Server.zig
+++ b/river/Server.zig
@@ -129,7 +129,6 @@ pub fn init(self: *Self) !void {
     _ = try wlr.DataControlManagerV1.create(self.wl_server);
     _ = try wlr.ExportDmabufManagerV1.create(self.wl_server);
     _ = try wlr.GammaControlManagerV1.create(self.wl_server);
-    _ = try wlr.ScreencopyManagerV1.create(self.wl_server);
     _ = try wlr.Viewporter.create(self.wl_server);
 }