Re: Proxying Wayland for security
On Wed, 28 Jul 2021 17:14:11 + Alyssa Ross wrote: > Pekka Paalanen writes: > > > On Wed, 28 Jul 2021 11:06:43 + > > Alyssa Ross wrote: > > > >> Daniel Stone writes: > >> > >> >> One big issue for us is protecting the system against potentially > >> >> malicious Wayland clients. It's important that a compartmentalized > >> >> application can't read from the clipboard or take a screenshot of the > >> >> whole desktop without user consent. (The latter is possible in > >> >> wlroots compositors with wlr-screencopy.) > >> >> > >> >> So an idea I had was to was to write a proxy program that would sit > >> >> in front of the compositor, and receive connections from clients. If > >> >> a client sent a wl_data_offer::receive, for example, the proxy could > >> >> ask for user confirmation before forwarding that to the compositor. > >> > > >> > As you've noted, the core protocol doesn't offer any way to scrape > >> > these contents without additional extension protocols, which are not > >> > implemented by all compositors. Generally speaking, GNOME's Mutter and > >> > Weston tend not to implement these protocols, and wlroots-based > >> > compositors tend to implement them. > >> > >> That's true for screenshots, but it's not true for clipboard contents, > >> right? As I understand it, any application can paste, with the only > >> restriction being that it has to be in the foreground at the time, and > >> wl-clipboard[1] seems to demonstrate that it's possible to fulfill that > >> requirement without being visible to the user at all. > >> > >> [1]: https://github.com/bugaevc/wl-clipboard/ > > > > Hi, > > > > I believe wl-clipboard only works, because we suck at implementing what > > we intended in compositors. Once compositors get fixed to correctly > > track and check input event serials, pasting will not be possible > > without the client in question getting an explicit input event. > > Furthermore, as sending input events from Wayland clients is generally > > not possible, the input must come from a source the compositor trusts - > > mostly likely from the human user. > > > > You can't get input events with legit serials without a visible window. > > > > Merely getting window (keyboard) focus should not be enough, there > > needs to be a proper input event like button, key or touch down. > > Pointer motion does not count either, nor do keys already down when > > gaining keyboard focus. > > > > I don't recall what the story for setting clipboard contents is. > > Thank you for the correction. Tt's still the case, though, that even > with a strict implementation, interacting with an application through a > mouse click or keyboard input would give it access to clipboard > contents. That's not at all obvious to users, and I don't think it's > something I could justify in a security-focused system, so I do still > need to do something about it. Yes. I believe the reason it was designed like this is because only the app/client knows what actions in that app should cause "paste". There could be a menu entry to select, a button to click, a key-combo to hit. Or maybe you are in a VR space and stabbing a tin can with a dagger is the equivalent to "paste". If you have a "are you sure you want to paste" dialog pop up every time an end user wants to paste something, I would bet the user will soon seek to let that app do pastes without asking. Then you are back at what Wayland intended to begin with. How do you intend to handle or waive that problem? > > Did you check > > https://github.com/mupuf/libwsm ? > > > > That was linked from the Weston issue. I don't know if it applies, and > > as you can see, it never took off and has been dormant for years. > > I only just saw it -- thanks for bringing it to my attention. It looks > like it could do the job, but it also looks like it would be difficult > to implement in compositors, since they seem to be responsible for > prompting the users for permission / notifying them of things that have > happened. > > Since this morning, I've been thinking about investigating polkit for > this, since this is (at least roughly) within its scope, it's already > present on just about every free desktop system, and desktop > environments already have the appropriate integrations with it. The me to first and foremost problem is what Simon McVittie wrote: How do you define and recognise a client's identity. Thanks, pq pgp6TEUc22sXc.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Proxying Wayland for security
Pekka Paalanen writes: > On Wed, 28 Jul 2021 17:14:11 + > Alyssa Ross wrote: > >> Pekka Paalanen writes: >> >> > On Wed, 28 Jul 2021 11:06:43 + >> > Alyssa Ross wrote: >> > >> >> Daniel Stone writes: >> >> >> >> >> One big issue for us is protecting the system against potentially >> >> >> malicious Wayland clients. It's important that a compartmentalized >> >> >> application can't read from the clipboard or take a screenshot of the >> >> >> whole desktop without user consent. (The latter is possible in >> >> >> wlroots compositors with wlr-screencopy.) >> >> >> >> >> >> So an idea I had was to was to write a proxy program that would sit >> >> >> in front of the compositor, and receive connections from clients. If >> >> >> a client sent a wl_data_offer::receive, for example, the proxy could >> >> >> ask for user confirmation before forwarding that to the compositor. >> >> > >> >> > As you've noted, the core protocol doesn't offer any way to scrape >> >> > these contents without additional extension protocols, which are not >> >> > implemented by all compositors. Generally speaking, GNOME's Mutter and >> >> > Weston tend not to implement these protocols, and wlroots-based >> >> > compositors tend to implement them. >> >> >> >> That's true for screenshots, but it's not true for clipboard contents, >> >> right? As I understand it, any application can paste, with the only >> >> restriction being that it has to be in the foreground at the time, and >> >> wl-clipboard[1] seems to demonstrate that it's possible to fulfill that >> >> requirement without being visible to the user at all. >> >> >> >> [1]: https://github.com/bugaevc/wl-clipboard/ >> > >> > Hi, >> > >> > I believe wl-clipboard only works, because we suck at implementing what >> > we intended in compositors. Once compositors get fixed to correctly >> > track and check input event serials, pasting will not be possible >> > without the client in question getting an explicit input event. >> > Furthermore, as sending input events from Wayland clients is generally >> > not possible, the input must come from a source the compositor trusts - >> > mostly likely from the human user. >> > >> > You can't get input events with legit serials without a visible window. >> > >> > Merely getting window (keyboard) focus should not be enough, there >> > needs to be a proper input event like button, key or touch down. >> > Pointer motion does not count either, nor do keys already down when >> > gaining keyboard focus. >> > >> > I don't recall what the story for setting clipboard contents is. >> >> Thank you for the correction. Tt's still the case, though, that even >> with a strict implementation, interacting with an application through a >> mouse click or keyboard input would give it access to clipboard >> contents. That's not at all obvious to users, and I don't think it's >> something I could justify in a security-focused system, so I do still >> need to do something about it. > > Yes. > > I believe the reason it was designed like this is because only the > app/client knows what actions in that app should cause "paste". There > could be a menu entry to select, a button to click, a key-combo to hit. > Or maybe you are in a VR space and stabbing a tin can with a dagger is > the equivalent to "paste". > > If you have a "are you sure you want to paste" dialog pop up every time > an end user wants to paste something, I would bet the user will soon > seek to let that app do pastes without asking. Then you are back at > what Wayland intended to begin with. > > How do you intend to handle or waive that problem? There's a lot of space in between "have a dialog every time a user wants to paste" and the current state of things. If a compositor checked with polkit whether a given client was allowed to paste, just for example's sake, it could potentially: * Refrain from asking again for a short amount of time, letting that client continue to paste in the meantime (auth_self_keep). * Be configured to always allow a client to paste from some other clients, but have to ask permission to paste from a non-allow-listed client. * Allow some clients to always paste, but not others. Even this is not possible today. In Qubes, an existing system with a respectably-sized userbase, using the clipboard between security domains requires a user to first copy to the security domain's clipboard, then copy from there to the global clipboard (Ctrl-Shift-C), then switch to the target domain, copy from the global clipboard into that security domain (Ctrl-Shift-V), and finally paste into the target application. Copying between applications within a security domain works as normal, without any of these extra steps. This system seems to work well for them, and is similar to my second example. Copying between security domains is a rare enough operation to justify some extra confirmation from the user to ensure it's deliberate. >> > Did you ch
Re: Proxying Wayland for security
On Thu, 29 Jul 2021 11:55:33 +0300 Pekka Paalanen said: > On Wed, 28 Jul 2021 17:14:11 + > Alyssa Ross wrote: > > > Pekka Paalanen writes: > > > > > On Wed, 28 Jul 2021 11:06:43 + > > > Alyssa Ross wrote: > > > > > >> Daniel Stone writes: > > >> > > >> >> One big issue for us is protecting the system against potentially > > >> >> malicious Wayland clients. It's important that a compartmentalized > > >> >> application can't read from the clipboard or take a screenshot of the > > >> >> whole desktop without user consent. (The latter is possible in > > >> >> wlroots compositors with wlr-screencopy.) > > >> >> > > >> >> So an idea I had was to was to write a proxy program that would sit > > >> >> in front of the compositor, and receive connections from clients. If > > >> >> a client sent a wl_data_offer::receive, for example, the proxy could > > >> >> ask for user confirmation before forwarding that to the > > >> >> compositor. > > >> > > > >> > As you've noted, the core protocol doesn't offer any way to scrape > > >> > these contents without additional extension protocols, which are not > > >> > implemented by all compositors. Generally speaking, GNOME's Mutter and > > >> > Weston tend not to implement these protocols, and wlroots-based > > >> > compositors tend to implement them. > > >> > > >> That's true for screenshots, but it's not true for clipboard contents, > > >> right? As I understand it, any application can paste, with the only > > >> restriction being that it has to be in the foreground at the time, and > > >> wl-clipboard[1] seems to demonstrate that it's possible to fulfill that > > >> requirement without being visible to the user at all. > > >> > > >> [1]: https://github.com/bugaevc/wl-clipboard/ > > > > > > Hi, > > > > > > I believe wl-clipboard only works, because we suck at implementing what > > > we intended in compositors. Once compositors get fixed to correctly > > > track and check input event serials, pasting will not be possible > > > without the client in question getting an explicit input event. > > > Furthermore, as sending input events from Wayland clients is generally > > > not possible, the input must come from a source the compositor trusts - > > > mostly likely from the human user. > > > > > > You can't get input events with legit serials without a visible window. > > > > > > Merely getting window (keyboard) focus should not be enough, there > > > needs to be a proper input event like button, key or touch down. > > > Pointer motion does not count either, nor do keys already down when > > > gaining keyboard focus. > > > > > > I don't recall what the story for setting clipboard contents is. > > > > Thank you for the correction. Tt's still the case, though, that even > > with a strict implementation, interacting with an application through a > > mouse click or keyboard input would give it access to clipboard > > contents. That's not at all obvious to users, and I don't think it's > > something I could justify in a security-focused system, so I do still > > need to do something about it. > > Yes. > > I believe the reason it was designed like this is because only the > app/client knows what actions in that app should cause "paste". There > could be a menu entry to select, a button to click, a key-combo to hit. > Or maybe you are in a VR space and stabbing a tin can with a dagger is > the equivalent to "paste". > > If you have a "are you sure you want to paste" dialog pop up every time > an end user wants to paste something, I would bet the user will soon > seek to let that app do pastes without asking. Then you are back at > what Wayland intended to begin with. That would be pretty nuts. It'd be more like ask once then flag that app as approved (dialog probably even has "no" "just this once" "as long as this app keeps running" "forever - always allow in future" options somewhere so the user is really approving for how long they want to approve for. To approve "forever" you do need some way to identify THIS client specifically again in future. Something that then cannot be easily faked (e.g. imagine every app in future has some 1024bit UUID or such generated the first time it is launched by some launcher and forever after that, that app in that context uses that UUID and advertises it to the compositor - well behaved clients then get ongoing behavior across sessions. Bad clients that ignore this get reset when they die and reconnect. As it's a massive UUID its not able to be faked and it is somehow stored so malicious clients can't harvest someone else's UUID). So given the general view that sandboxed clients are untrusted, the sandboxing mechanism can store the UUID inside the sandbox only that client can access. Regular apps just have the UUID stored in ~/.config somewhere which the sandboxed clients cannot read. > How do you intend to handle or waive that problem? > > > > > Did you check > > > https://github.com/mupuf/libwsm ? > >
Re: [Mesa-dev] Requests For Proposals for hosting XDC 2022 are now open
Remember before enjoying your holiday that the deadline for XDC 2022 proposals is *September 1st, 2021* :-) Feel free to submit your proposal before, so we can give you early feedback on it! Sam On Thu, 2021-07-01 at 18:14 +0200, Samuel Iglesias Gonsálvez wrote: > This is a reminder that the call for proposals for hosting XDC 2022 > period finishes in two months. > > Be sure to prepare your submission before you leave on holiday! > > Sam > > On Thu, 2021-05-20 at 12:15 +0200, Samuel Iglesias Gonsálvez wrote: > > Hello everyone! > > > > The X.org board is soliciting proposals to host XDC in 2022. Since > > XDC 2021 is being held in Europe this year (although virtually), > > we've > > decided to host in North America. However, the board is open to > > other > > locations, especially if there's an interesting co-location with > > another conference. > > > > Of course though, due to the ongoing COVID-19 pandemic it's not yet > > clear whether or not it will be possible to host XDC 2022 in > > person, > > although is seems very likely. Because of this, we would like to > > make it clear that sponsors should prepare for both the possibility > > of an in person conference, and the possibility of a virtual > > conference. We will work with organizers on coming up with a > > deadline for deciding whether or not we'll be going virtual, likely > > sometime around July 2022. > > > > If you're considering hosting XDC, we've assembled a wiki page with > > what's generally expected and needed: > > > > https://www.x.org/wiki/Events/RFP/ > > > > When submitting your proposal, please make sure to include at least > > the > > key information about the potential location in question, possible > > dates along with estimated costs. Proposals can be submitted to > > board > > at foundation.x.org until the deadline of *September 1st, 2021*. > > > > Additionally, an quirk early heads-up to the board if you're > > considering hosting would be appreciated, in case we need to adjust > > the > > schedule a bit. Also, earlier is better since there generally will > > be > > a > > bit of Q&A with organizers. > > > > And if you just have some questions about what organizing XDC > > entails, > > please feel free to chat with previous organizers, or someone from > > the > > board. > > > > Thanks, > > > > Sam > > > > ___ > > mesa-dev mailing list > > mesa-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > ___ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
