00:04 <DemiMarie> kennylevinsen: clipboard access extensions are a serious security risk when used with SSH, unless the clipboard content is transmitted via an out of band mechanism.

00:06 <kennylevinsen> DemiMarie: see OSC-52

00:07 <DemiMarie> kennylevinsen: which has known security problems

00:08 <DemiMarie> When using a non-sandboxed application (which is most CLI applications), it really is more secure to connect to the Wayland compositor directly, rather than to communicate with the terminal emulator.

00:09 <kennylevinsen> not sure I agree

00:10 <kennylevinsen> But you have the same security issue when using e.g. waypipe, rdp, SPICE, …

00:10 <emersion> the wayland socket can only grant extra privileges compared to the escape codes provided by the wayland terminal emulator

00:11 <DemiMarie> emersion kennylevinsen: the difference is that the Wayland socket is only available to local applications, whereas the escape codes are available to remote applications.

00:11 <kennylevinsen> I think Demi’s idea is that it would then not work over ssh, which would then of course be extremely annoying over ssh

00:11 <zamundaaa[m]> Demi: unless you give all apps clipboard access all the time, you can't make that work

00:11 <zamundaaa[m]> You need a focused surface to get clipboard access, which terminal applications don't have, local or not

00:11 <emersion> i mean… the whole point is to make it work over ssh

00:12 <DemiMarie> emersion: seriously?

00:12 <DemiMarie> that was not at all what I was expecting

00:12 <emersion> the whole point of OSC-52, yeah

00:12 <emersion> (and also make it WSI-independant, i suppose)

00:12 <emersion> (but CLI apps have long just invoked xclip and such)

00:13 <DemiMarie> to me, the best solution is to replace the old terminal with an explicit protocol

00:14 <DemiMarie> kennylevinsen: breaking clipboard access over SSH is the point. I don’t want remote applications to have clipboard access.

00:14 <DemiMarie> More specifically, I don’t want them to have implicit clipboard access.

00:15 <DemiMarie> My usual assumption with SSH is that the remote host is less trusted with the local one and should not be able to access the user’s clipboard without user confirmation.

00:15 <DemiMarie> That said, this is a valid difference in threat model.

00:16 <emersion> you grant any webpage clipboard access

00:16 <emersion> ssh is not very different here

00:16 <zamundaaa[m]> Demi: like I said, you can't do that without opening up more security holes in Wayland

00:16 <mclasen> who knows what you grant a webpage nowadays...

00:16 <zamundaaa[m]> If there's issues in how terminal emulators grant access to the clipboard, then those issues have to be fixed

00:16 <DemiMarie> emersion: I believe I don’t, actually. I disable that via a Chrome policy.

00:17 <emersion> you can disable OSC-52 in the same way

00:17 <DemiMarie> emersion: what I would like (and was very easy with X11) is to have it enabled for local apps _only_.

00:18 <emersion> i don't see how wayland changes things

00:18 <DemiMarie> emersion: `wl-clipboard` not working would be annoying

00:18 <DemiMarie> but this is also a very valid difference of opinion

00:18 <emersion> i don't understand

00:19 <DemiMarie> zamundaaa: I would use security-context to restrict sandboxed apps while unsandboxed apps have full access.

00:19 <emersion> you want to make OSC-52 not work? and you're talking about wl-clipboard, which isn't used by OSC-52?

00:19 <mclasen> there seem to be two opposing opinions here

00:20 <emersion> disabling OSC-52 would be done by configuring the terminal emulator

00:20 <emersion> or is it something else that you want?

00:20 <DemiMarie> emersion: if wl-clipboard doesn’t work, then OSC-52 is the only way (that I know of) for a _local_ Wayland application to access the clipboard, but that is also available to _remote_ Wayland applications.

00:20 <mclasen> 1) osc 52 makes the clipboard accessible to remote apps - bad

00:20 <mclasen> 2) xclip makes the clipboard unconditionally accessible to any local app - good

00:20 <mclasen> at least that is how I understand what DemiMarie is saying

00:20 <DemiMarie> mclasen: all _unsandboxed_ local apps

00:21 <DemiMarie> to me, there is no point in protecting from something that could write to ~/.profile.

00:21 <mclasen> there's no sandboxing in X to limit that

00:21 <DemiMarie> mclasen: am I being confusing here?

00:22 <DemiMarie> My assumption is that sandboxed apps don’t have X11 access.

00:22 <mclasen> yes, if your compositor does the security contex thing, you could make that distinction

00:22 <DemiMarie> exactly!

00:23 <mclasen> I don't think it is very useful

00:25 <emersion> it allows GNOME to reliably identify apps asking to intercept global compositor bindings

00:25 <emersion> even for GNOME, it is useful

00:25 <emersion> (for non-GNOME, it's even more useful)

00:26 <mclasen> we'll use a portal

00:26 <emersion> even then, it allows GNOME to reliably identify apps setting their xdg_toplevel.app_id

00:27 <mclasen> there's great utility in being able to identify apps

00:27 <mclasen> but I don't see why my compositor needs ot be involved in that

00:27 <mclasen> the only reason would be to pretend that dbus doesn't exist

00:28 <emersion> thanks for the productive comments

00:28 <mclasen> but we can agree to disagree on that

00:29 <Company> are we doing nesting of security contexts?

00:30 <Company> the biggest problem with all of this is that in the mind of users, "the clipboard" is a global thing

00:31 <Company> so whatever method anyone comes up with for securing it will be unintuitive because it breaks that assumption

00:35 <Muzer> cheers for the pointers, I've patched out the checks in kwin so now I can have the X clipboard work as it did in X :)

00:35 <Muzer> works a treat

00:37 <Muzer> incidentally to add to the debate, FWIW I use ssh x forwarding at work. Literally the only reason I do this is to get clipboard integration between my remote vim instance running on a Linux server and my work-issued Windows machine (via WSL), along with the occasional command-line use of xclip

00:44 <DemiMarie> Company: you can ask Qubes OS how to de-train users of that assumption

00:44 <Company> I don't think users want to be de-trained

00:44 <YaLTeR[m]> arguably if you're using a system that clearly puts security front and center, you're already expecting things to not always work

00:45 <Company> the first interop thing everyone always does is make the clipboard work

00:45 <DemiMarie> YaLTeR: that is somewhat true, but we work hard to make as much work as possible.

00:45 <Company> so you can copy/paste into/out of your vms

00:46 <zamundaaa[m]> Company: that's not really true actually, spice-vdagent doesn't have any Wayland support yet

00:47 <zamundaaa[m]> It only works on Gnome because it gives X11 apps unconditional access to the clipboard

00:47 <DemiMarie> Qubes OS does have a global clipboard, but access to it is explicit, not implicit, which solves the security problems.

02:30 <DemiMarie> Regarding enums: could there be an on_out_of_range attribute in the XML, which would both specify that out of range values are a protocol error and specify the specific error to use?

19:17 <wlb> wayland-protocols/main: Simon Ser * xdg-shell: clarify clients set their initial state before initial commit https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/b4a42c88f49d stable/xdg-shell/xdg-shell.xml

19:17 <wlb> wayland-protocols Merge request !333 merged \o/ (xdg-shell: clarify clients set their initial state before initial commit https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/333)

19:41 <Muzer> <YaLTeR[m]> arguably if you're using a system that clearly puts security front and center, you're already expecting things to not always work <-- indeed but since Wayland is being touted by distros as a general-purpose replacement for X I don't think most users would perceive it as "putting security front and centre", or even want that when it involves compromising functionality. After all, realistically for most people, if someone has access to your user,

19:41 <Muzer> it doesn't matter whether or not they have access to the clipboard, it's pretty much game over. You can do all sorts of damage with someone's browser cookies without even having to know their passwords. So with this in mind this particular brand of clipboard security seems particularly obtuse to me... which is why I patched it out :) given kwin already has user-configurable options for allowing X apps global access to the keyboard, I think I might try to

19:41 <Muzer> upstream a config option to the same effect for the clipboard.

19:41 <YaLTeR[m]> I was talking about qubes os

19:42 <Muzer> ah sorry

19:42 <Muzer> I saw that message but didn't make the contextual link

19:46 <kennylevinsen> well, any general purpose OS must put security front and center, QubesOS just takes that further and makes tradeoffs that the average user might deem unacceptable

19:47 <kennylevinsen> variation is good though - people have different tastes, preferences, and (in case of security) things to worry about

19:47 <Muzer> absolutely agreed

19:50 <Muzer> for the example of my work usage of the X11 clipboard especially - if someone external has access to my X forwarding session that's already a horrendous security breach that could have huge implications. The fact that they can also get access to the code/log lines/whatever I'm copying between Windows and the remote development server is so far down my list of priorities at that point that I'm not really willing to make any usability sacrifices to prevent it...

19:50 <Muzer> (of course you could argue that's a moot point as I suspect this sort of use case is going to be one of the last hold-outs of X over wayland, but whatever)

19:51 <kennylevinsen> note that there is a difference to variation vs. adding big toggles to change fundamental behavior

19:51 <kennylevinsen> if compositors in general had a "security off" button, apps would start getting written to require security to be off, and then users would no longer be able to use their system with security on, making it all for nothing

19:52 <Muzer> perhaps it's my imagination but I've always found KDE to be fairly keen on its big toggles for fundamental behaviour, by comparison to other desktop environments

19:52 <kennylevinsen> Those toggles are not fundamental behavior, they're just preferences

19:53 <Muzer> what is really the difference here between what I'm proposing and the existing toggles for allowing legacy X apps global access to the keyboard and mouse?

19:53 <Muzer> because that toggle already exists

19:53 <kennylevinsen> Toggles for fundamental behavior is like compiling your kernel without filesystem permission support, so everything is free for all

19:54 <kennylevinsen> there's a big difference between *that*, and changing between single-click or double-click, moving your systray, changing your fonts, etc.

19:55 <kennylevinsen> The KDE toggle for global keyboard and mouse access is already a very special workaround that I don't think anyone else has - and I don't think KDE *wants* to have it either, I imagine it's just temporary

19:55 <kennylevinsen> but I can't comment on that

19:57 <zamundaaa[m]> With the adoption rate of the global shortcuts portal, "temporary" will be a long time. But yes, it's not supposed to stick around forever