Daniel Stone <dan...@fooishbar.org> 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/ >> I could just implement this stuff in a compositor, but doing it with a >> proxy would mean that a known subset of the protocol could be used >> with any compositor, with appropriate access controls. It would also >> be a reusable component that could be customised to have different >> access control policy depending on the needs of a distributor or user. > > I think you'd be better off dealing with the problem at source. > libwayland-server already has a 'global filter' mechanism which allows > an arbitrary hook to decide which clients can and cannot see which > interfaces. This is used to advertise private protocols to trusted > clients: for example, Weston's UI and screenshot support are handled > by external clients, but we use the filter to ensure that _only_ those > clients can access those protocols, not arbitrary clients. > > Implementing a proxy just shifts this problem rather than solving it > once; every time someone adds a new protocol, you have to plumb it > through the proxy and add some kind of policy mechanism. But the > compositors themselves probably have their own policy mechanism, so > why not just reuse that? Because that requires work for every compositor, whereas a proxy would have allowed it to be done just once, and then to work with all compositors. But Carsten's mail convinced me that a proxy is indeed probably not a good idea, and I should instead pursue integrating these existing policy mechanisms with some sort of compositor-independent policy decision maker. > Cheers, > Daniel
signature.asc
Description: PGP signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
