Carsten Haitzler <ras...@rasterman.com> writes: > On Tue, 27 Jul 2021 19:29:45 +0000 Alyssa Ross <h...@alyssa.is> said: > >> Hi! I'm Alyssa and I'm working on Spectrum[1], which is a project >> aiming to create a compartmentalized desktop Linux system, with high >> levels of isolation between applications. >> >> 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. > > The above is intended to be the job of the compositor. I would expect > compositors to implement this. The only decisions to be made is which clients > do they "lock down" and ask questions for (eg like allow copy yes/no) and > which > they do not. The compositor has a socket to the client and can use that to > figure out all about the client that it wants to. > >> 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. > > You could - but then the compositor thinks your proxy is the client, not the > actual client. This leads to lots of un-fun like if a compositor uses the > client socket to query what PID and then what executable etc. that is and does > things like shows icons based on the executable found (what desktop file that > maps to) etc. ... If the compositor implements some kind of load balancing of > rendering/updates based on PID. e.g. it may renice the PID of the client based > on if its on a visible virtual desktop or not. I can go on... > >> Which brings me to the reason I'm bringing this all up on >> wayland-devel. I'd be grateful for any input about this idea, >> especially: >> >> * Is this a sensible idea? Is there something I haven't considered >> which would make this unworkable, and force me to do a >> compositor-specific implementation instead? > > See above. I can come up with more things that will be problematic. Sure. it > *CAN* be done. In some cases like a "vnc proxy" whose job it is to display > remote clients it deals with over vnc to a local wayland compositor... it's > pretty much necessary. The above socket -> pid -> exe etc. isn't going to be > valid/useful and you can't really do that due to the real client being "off > machine". But for the vast vast majority of cases, they will be real local > clients with real PIDs etc.
A further thought I've just had -- the pid lookup is generally done through libwayland-server's wl_client_get_credentials(), right? So if libwayland-server could be taught about the proxy, and the proxy could communicate the pid/uid/gid to libwayland-server somehow, that could make this possible after all, right? (Assuming that the small amount of extra complexity in libwayland-server was judged to be worth it to allow this degree of compositor-independent add-on functionality, of course.)
signature.asc
Description: PGP signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
